Yes, an AI assistant can build a Shopify profit dashboard in an afternoon, and it will run. What it rarely gets right are Shopify's data rules: two dates per order, tax-exclusive prices, shipping before discounts, refunds that move no money, gift cards, other currencies, plus tokens that expire and API versions that retire. Build it if someone will maintain it.
Asking an AI assistant to build a profit dashboard for a Shopify store is a reasonable idea in 2026, and the first afternoon is genuinely impressive: orders arrive through the Admin API, a chart shows revenue minus product costs, and the numbers look plausible. The trouble comes later, and quietly. Profit on Shopify is a set of rules about which day an amount belongs to, which price is the real one and which money was never revenue, and code that does not know a rule does not fail. It produces a confident, slightly wrong number every day. This page lists the rules a profit engine has to get right, every one of them a rule nouz's own engine had to learn, what Shopify's API now asks of any app that reads a store, and when building your own is still the better call.
In short
- The code is the easy part. The rules are the product: eighteen of them decide whether a home-built tracker's margin is right, and none of them raises an error when it is missed.
- Shopify's side keeps moving: a new API version every three months, access tokens that expire after an hour, and approval steps before an app may read orders older than 60 days or a customer's name.
- The ad platforms are projects of their own: Meta's Marketing API and the Google Ads API each have access levels to reach before a tool runs against live accounts.
- Build it when a developer will own it for years and your question is one no tool asks; otherwise buy the rules instead of rebuilding them.
Can AI build a Shopify profit dashboard?
Yes, and quickly. Give an AI coding assistant such as ChatGPT, Claude or Cursor access to a development store and a description of what you want, and it will write the GraphQL query for orders, sum the line items, subtract a cost per product, add the ad spend you paste in and draw a daily chart. On a store with simple orders the first numbers can even be right. That is what makes the approach attractive and what makes it risky: the model writes exactly what it was asked for, and nobody asked it about the order imported from another platform, the refund that moved no money or the gift card sold in December.
Review does not catch it either. Code review finds syntax errors and slow queries; it does not find a refund booked in the wrong month, because the code that books it there runs perfectly. The errors in a profit tool are accounting errors expressed as working software, and they show up only when someone compares a day line by line with the bank, the payouts and Shopify's own reports.
What does a home-built Shopify profit tracker get wrong?
The sales side first. Every row below is a rule nouz's engine runs on, and each is a place where the obvious code gives a plausible, wrong answer.
| Rule | What quick code tends to do | What the statement needs |
|---|---|---|
| Which date an order has | groups orders by createdAt, the moment the order entered Shopify | processedAt, so an order imported from another platform keeps the day it was really processed |
| Prices with or without tax | treats every price as tax-inclusive | orders whose prices exclude tax, the norm in the US and Canada and in net-price B2B, put on the same basis first |
| Shipping | reads a shipping total | the shipping charged after shipping discounts, or every free-shipping code books waived shipping as revenue |
| When a refund counts | subtracts it from the month of the original order | the day the refund was issued, so a closed month stays closed |
| What a refund takes back | the money that moved | the goods and value taken back: an item removed before payment is a refund of no money that still counts |
| Exchanges | a refund, or nothing | the new item sold on the day of the exchange, the replaced one returned that day |
| Gift cards | a gift card sold counts as revenue | a liability until it is spent; spending it is a way to pay |
| Chargebacks | ignored until the payout looks short | the disputed amount taken back as a return, on the day the dispute is lost |
| Cancelled and test orders | summed with the rest | left out, except the fee on a payment taken before the order was cancelled |
| Other currencies | adds every order's figures as they are | orders stored in another currency converted into the store currency, to the cent |
Then the costs, where the time dimension does most of the damage.
| Rule | What quick code tends to do | What the statement needs |
|---|---|---|
| Cost changes | one cost per product, so every edit rewrites the past | every cost with the date it applies from; last quarter keeps last quarter's cost |
| Cost of a returned unit | credited at today's cost | credited at the cost that was valid when the unit was sold |
| Weights | 0 g read as weightless | Shopify's default 0 g read as unknown, and flagged |
| Shipping cost | one flat amount per order | each parcel priced by zone and by weight or size; a split shipment pays two labels |
| Payment fees | one percentage for every order | a rule per payment method, and on Shopify Payments the fee Shopify reports on each payment |
| Fixed costs | booked on the day the invoice arrives | spread across the days they cover, a monthly cost at twelve times the month over 365 a day |
| The day itself | buckets in UTC | buckets in the store's own time zone, so yesterday is the store's yesterday |
| Missing costs | counted as zero | flagged, because a zero cost is an invented margin |
Each row has a page of its own on this site, worth reading before writing the code for it. The timing rules are in which day a refund belongs to and in store timezones and the month boundary; the revenue rules in gift cards are not revenue, exchanges on a P&L, a chargeback and a return are not the same cost and cancelled and test orders; the tax and currency rules in the help pages on prices that exclude tax and on orders in another currency, where Shopify's own converted figures arrive with three decimals and have to be rounded once per line, not per unit. On the cost side, effective dating is the rule behind the first two rows, proration the one behind fixed costs, what Shopify's cost field keeps explains why Shopify's own cost history is not enough, and the help page on missing weights covers the weightless parcel. Two smaller ones cost real money over a year: the payment fee nobody refunds, and the rounding drift of a cent per parcel.
What does Shopify's API demand of a home-built tool?
More than it did a year ago. Since 1 January 2026 a merchant can no longer create a custom app in the Shopify admin; apps made that way keep working, and a new one is created in Shopify's Dev Dashboard instead. An app is either public or limited to one store, or to the stores of one Plus organisation, and Shopify's page on app distribution says the choice cannot be changed once it is made, so a tool built for one store stays a tool for one store.
Reading orders is a permission with conditions. By default an app sees only the last 60 days of a store's orders; the full history needs the read_all_orders scope, which a public app requests from Shopify and may add once Shopify approves it. Orders, refunds and transactions are protected customer data, so an app requests that access too and meets Shopify's requirements for it, and the level that includes names, addresses, emails and phone numbers adds data protection reviews.
Then the plumbing. An offline access token, the one a background sync uses, now expires after an hour and is renewed with a refresh token that lasts 90 days and is replaced at every refresh; Shopify's page on expiring offline access tokens says public apps must use them for GraphQL Admin API requests by 1 January 2027. The GraphQL Admin API's rate limits meter every query by cost: 100 points a second on the standard plans, 200 on Advanced, 1.000 on Plus, and no single query may cost more than 1.000 points. A full order history needs bulk operations: since API version 2026-01 an app may run up to five bulk queries per store at once, the results arrive as JSON Lines behind a link that expires after a week, and a query may hold at most five connections, nested two levels deep.
Each stable version is supported for a minimum of 12 months Shopify, API versioning, shopify.dev, checked 21 Oct 2026
And every three months a new API version. Shopify's versioning policy releases one each quarter, supports each for at least a year, and answers a call to a retired version with the oldest version still supported, which can change what a field returns without a line of your code changing. Four times a year somebody has to read the release notes and check the queries. An app listed on the Shopify App Store must also answer three privacy webhooks, for a customer's data, a customer's erasure and a shop's erasure, within 30 days; a tool for one store is spared the listing but not the GDPR, because it still holds customer data.
What about ad spend from Meta and Google?
Each platform is its own integration with its own access rules. Meta's Marketing API authorization page says standard access to the ads permission is enough when an app manages your own ad account, while reading other businesses' accounts needs advanced access through App Review; it labels its default Marketing API tier as meant for development, and full access asks for at least 500 Marketing API calls in 15 days with an error rate under 15%.
Google Ads works through a developer token. Google Ads API access levels set out the steps: the Test level reaches only test accounts, Explorer reaches live accounts at 2.880 operations a day, and Basic, which needs brand verification of the Google Cloud project and an application, allows 15.000 operations a day. TikTok, Pinterest, influencer budgets and affiliates each add a source of their own, and every platform reports in its own ad account's time zone and currency, which have to meet the store's before a day's marketing cost is right.
What does it cost to keep a home-built tracker running?
The first version is the cheap part. After it come four API versions a year to check, tokens to refresh and store safely, encrypted at rest and never written to a log, a database and its backups, a scheduled sync that resumes when a bulk operation fails halfway, monitoring that notices when a night's sync did not run, and an answer every time somebody asks why yesterday's number differs from Shopify's. Each new edge case, the first exchange, the first order in Swedish kronor, the first chargeback, is a change to a live system that has to be made without rewriting the months already reported.
The quieter cost is attention. A tracker is an instrument, and the hours spent maintaining it are hours not spent acting on what it says, which is the same trap a profit spreadsheet sets; the page on moving off the spreadsheet describes the moment the sheet becomes the work rather than the tool, and a home-built app reaches that moment faster, because it fails less visibly.
How do you test whether a home-built tracker is right?
- Refund an order from last month and check that last month does not move.
- Exchange an item and check that the new item is sold on the day of the exchange.
- Sell a gift card, redeem it a week later, and check that revenue rises once, on the redemption order's goods.
- Place an order with a free-shipping code and check that shipping revenue is zero.
- Take an order whose prices exclude tax and one in another currency, and check both land on the same basis as the rest.
- Enter a supplier increase dated three weeks ago and check that only the last three weeks re-price.
- Find a product without a weight and check that it is flagged rather than shipped for free.
- Then compare one finished day against Shopify's own sales report and explain every difference by a rule.
When does building your own make sense?
When three things are true at once. A developer will own the tool for years, not for a sprint. The store is simple enough that most rules above never fire: one currency, prices with tax included, few refunds, one carrier at one price. And the question is one no tool asks, a margin model built around a specific supply chain, say, or data that already lives in a warehouse a team maintains. In that case the rules on this page are a specification, and the work is worth doing. A home-built tracker is also a good way to learn a store's economics, the way a spreadsheet is; the risk is only in trusting it before every rule is in.
What does a tool like nouz do instead?
It is those rules, maintained. nouz reads the store through Shopify's Admin API with read-only access, brings back its entire order history on the first sync, reads ad spend from Meta, Google and TikTok, and turns every day into a 34-line P&L from gross merchandise value down to EBITDA, with CM1, CM2 and CM3, the margins after goods, after shipping and fees and after ads. Its engine is built on the rules in the two tables above, one written rule per line of the statement, and the methodology page sets out how every line is computed. Every cost type is kept with the date it applies from, a missing cost is flagged rather than counted as zero, and a Forecast page, Insights per product and customer, and a daily profit email sit on the same numbers. Each of these claims about nouz is listed, with where to check it, on the nouz facts page.
It is priced as a tool rather than a project: Base $55, Pro $115 and Scale $289 a month (about €49, €99 and €249), every feature on every plan, a 14-day trial, and what each plan covers under nouz's pricing. A store that wants to compare the whole category first will find it in the best Shopify profit tracking apps, and a store that needs an ERP for purchasing and stock as well will find that route in Odoo alternatives for Shopify.