Ask an ecommerce founder what their business made last month and you will get a number. Ask which of their 40 SKUs actually made money and the answer gets slower, vaguer, and usually wrong. This is not a competence problem. It is a structural one, and it has a structural fix.
That quote is the whole problem in one sentence. The seller does not want analytics. They want a number they can trust that stays true without anyone babysitting it. Here is why that is hard, and what it takes to actually build it.
Why the per-SKU number is genuinely hard
The fee surface is enormous and moving
Amazon alone bills sellers through more than 40 distinct fee types: referral fees, FBA fulfillment fees by size tier, monthly storage that changes rate by season, long-term storage surcharges, inbound placement fees, low-inventory-level fees, aged-inventory surcharges, removal and disposal fees, refund administration fees, and on down the list. Several of these changed materially in the last two years, and the 2026 additions, like low-inventory fees at the FNSKU level and aged-inventory thresholds that start counting at day 181, are tied to inventory behavior, not just sales. Your margin on a SKU now depends on how well you restock it.
Ads have to be attributed, not averaged
Most brands subtract total ad spend from total profit and call it TACoS. Fine for the P&L, useless per SKU. Spend has to be attributed to the products it actually supported, including halo effects where ads on one ASIN drive sales of another. Average it and your hero SKU subsidizes your losers invisibly, which is exactly the failure the per-SKU exercise exists to catch.
The truth arrives weeks late
A sale on the 1st is not settled on the 1st. Returns come back for weeks. Reimbursements for lost and damaged inventory land as separate adjustments, at manufacturing cost, on their own timeline. Chargebacks, promo clawbacks, and fee corrections trickle in across settlement periods. Any profit number computed the day after a sale is a draft. Systems that never reconcile drafts against actual settlement deposits drift away from reality, and the drift compounds.
Landed cost is nobody's job
The Amazon-side fees are at least in reports somewhere. Your true cost side, factory cost, freight, duties, prep, storage between 3PL and FBA, often lives in old emails and a freight forwarder's invoices. Without a maintained landed-cost figure per SKU, every downstream calculation is built on a guess.
Why the usual fixes fail
The spreadsheet dies because it is a snapshot. It encoded the fees and prices of the week it was built, and Amazon changes both continuously. Within a quarter it is quietly wrong, and quietly wrong is worse than absent, because you keep making decisions on it.
The off-the-shelf dashboard gets further, and for some brands it is enough. But the common gaps are consistent: landed cost is approximated or manually entered once and never updated, off-Amazon channels and costs are out of scope, numbers are not reconciled against settlement deposits, and the tool reports on its schema rather than answering your actual questions. Plenty of brands pay for a profit dashboard and still cannot answer "which SKUs do we kill this quarter."
The custom BI build can be right, and when sellers hire developers for this it typically runs $5-15K. The failure mode is that it gets built as a project instead of a system: it works on delivery day, then fee schedules change, an API version deprecates, the developer is gone, and you own a second spreadsheet problem that cost five figures.
The AI Operations Audit maps where your profit data actually lives, what your current tooling gets wrong, and what a self-updating system costs to install in your specific stack. $2,500, or $7,500 for 8-9 figure brands.
See the AI Operations AuditWhat a self-updating system actually requires
I run StackEasy, my own software company, on 130+ automated systems, and the pattern that works for profit truth is the same one that works everywhere: feeds, a model, event-driven recompute, reconciliation, and alerts. Five parts.
1. Automated feeds, not exports
Settlement reports, fee previews, the ads API, returns data, and inventory ledgers pulled on schedule by the system, not downloaded by a human when they remember. The moment a human is the pipeline, the pipeline has an uptime problem.
2. A landed-cost model per SKU that someone owns
Factory cost, freight, duties, and prep maintained as structured data with effective dates, so the system knows what a unit cost in March versus August. This is the one input that genuinely needs periodic human upkeep, so the system should make that upkeep a five-minute task with a reminder, not an archaeology project.
3. Recompute on events, not on memory
When a fee schedule changes, a price moves, or a settlement file lands, the numbers recompute. That is the literal answer to "a spreadsheet that updates itself": the trigger is the event, not a person.
4. Reconciliation against the bank
Every period, the model's bottom line gets checked against what Amazon actually deposited. If the model says you earned $84K and the deposits say $79K, the system finds the $5K, because untraced gaps are how models drift into fiction.
5. Alerts at the decision points
The output is not another dashboard to check. It is a short list of changes that need a decision: this SKU went margin-negative after the fee update, this one is about to cross the 181-day aged-inventory threshold, this one's return rate just doubled. Humans make the calls. The system makes sure the calls get surfaced while they are still cheap.
None of this is exotic engineering. It is plumbing, done once, owned properly. The brands that have it make kill, restock, and pricing decisions on numbers that are actually true. The brands that do not are managing a portfolio of SKUs where some unknown fraction loses money on every unit, and the winners pay for it.
Questions sellers ask
Why is per-SKU profit so hard to calculate on Amazon?
Because the cost side is fragmented across 40+ fee types that change on their own schedules, ad spend that needs attribution down to the SKU, returns and reimbursement adjustments that arrive weeks after the sale, and storage fees that vary by month and inventory age. No single report contains all of it, so any per-SKU number has to be assembled from multiple feeds and kept current as the inputs move.
Why do profit spreadsheets always break?
Spreadsheets capture a snapshot of fees and prices on the day they were built, and Amazon changes both continuously. Every fee update, price move, and new fee type silently invalidates the model unless someone manually maintains it, and nobody maintains it for long. The fix is not a better spreadsheet, it is a system that re-pulls the inputs and recomputes on its own.
Don't profit dashboards like the analytics SaaS tools solve this?
They get partway. Off-the-shelf dashboards are good at marketplace fees but typically weak on true landed cost, off-Amazon costs, and reconciliation against actual settlement deposits. They also report on their schema, not yours. Many brands run a dashboard and still cannot answer which SKUs to kill, which is the question the whole exercise exists for.
What does a self-updating per-SKU profit system require?
Five things: automated feeds from settlement reports, fee schedules, ads data, and returns; a maintained landed-cost model per SKU; recomputation triggered by events rather than by someone remembering; reconciliation so the model's total matches the bank deposit; and alerts when a fee change or margin move actually needs a human decision.