The most common complaint about Shopify profit tracking apps and dashboards is that the numbers don't match reality. This isn't a bug. It's a design choice every tool makes, usually without telling you. This guide gives you the framework to know whether any profit number you're looking at is ACTUAL data or an ESTIMATED model, and five questions to ask any vendor before trusting their margin reports.
Who this is for: $3-12M DTC founders and finance leads evaluating or currently using a profit reporting tool, and anyone who has ever looked at a margin number and thought "that can't be right."
Last updated: May 2026
The test: Can your profit tool tell you, for any given margin number, whether it's ACTUAL or ESTIMATED? If not, every number in the dashboard carries unknown confidence.
Read the G2 reviews for any Shopify profit tracking app used by DTC brands (TrueProfit, BeProfit, Triple Whale, Polar Analytics, Sellerboard) and you'll find the same pattern repeated across hundreds of reviews: "The numbers don't match my Shopify data," "Margins are significantly off compared to our books," "I've been using this for 6 months and still can't trust the profit number."
Based on public G2 reviews for tools like these, last checked 2026-05.
These are not edge cases from unsophisticated users. These are signals from operators running $3-15M brands who plugged in a tool, followed the setup instructions, and still got numbers they couldn't reconcile.
The reviews share a common frustration: the tool produces a confident-looking number (a clean dashboard, a margin percentage, a profit trend chart) that turns out not to reflect reality when tested against bank statements, 3PL invoices, or actual carrier costs.
The tool isn't lying. It's estimating. And the problem is that it doesn't say so.
A complete profit number for a DTC brand requires data from multiple disconnected sources:
In practice, no profit tool has live, first-party connections to all of these systems at once, especially carrier invoices and 3PL billing files, which are often PDFs or CSVs emailed monthly. Most of these systems simply don't expose reliable APIs: carrier invoices arrive weekly as PDFs, 3PL billing files are often emailed as CSVs, and freight costs live in a PO system that doesn't talk to Shopify.
So tools fill the gaps. They use the COGS you entered in Shopify (often a round number or an estimate). They use an average shipping cost you entered during setup. They use industry-average processing fees. They use a blended return rate across your whole catalog.
None of this is wrong in principle. The problem is when these estimates are presented with the same visual confidence as actual data (same font, same dashboard widget, same "profit" label) with no indication of how they were calculated or how confident you should be in them.
The result is a dashboard full of numbers that look precise but carry unknown amounts of estimation. You don't know which margins are based on real invoices and which are based on the $5 average shipping cost you entered in month one and never updated.
The solution to the unknown-confidence problem is labeling. Every metric in a profit reporting system should carry one of two tags:
In practice: a green ACTUAL badge means "this number came from a real document." An amber ESTIMATED badge means "this number came from a model or manual input."
A metric tagged ACTUAL was derived from a verified source document: a carrier invoice, a 3PL billing file, a Shopify transaction record, a payment processor statement, or a supplier PO. The specific source document and the calculation method can be traced.
ACTUAL data has three properties:
ACTUAL data is the right basis for high-stakes decisions: SKU discontinuations, price changes, channel mix shifts, investor reporting.
A metric tagged ESTIMATED was derived from a model, assumption, or blended average rather than a specific source document. This includes:
ESTIMATED data is not useless. It's often good enough for directional decisions, trend monitoring, and early-stage planning when real source data isn't yet available. But it should be treated with appropriate skepticism for high-stakes decisions, and it should be replaced with ACTUAL data as quickly as data sources become available.
Every ESTIMATED metric should carry a methodology trace: a short note documenting how the number was calculated, what assumptions were made, and when it was last verified.
Example methodology trace for an estimated shipping cost metric:
A methodology trace turns an opaque number into an auditable one. It tells you not just what the number is, but how confident you should be in it and what it would take to upgrade it to ACTUAL.
Most profit dashboards blur estimates and facts together. MarginOS does the opposite. It makes the status of every number obvious on the surface, then lets you open the receipts behind it. Three views work together: a status pill on every cost layer, an evidence drawer that shows the source documents, and an integration panel that shows where the evidence comes from and how fresh it is.
In the Cost Stack & Overrides panel, each cost layer for a SKU (base product, freight, inbound handling, storage, fulfillment, gateway fees) sits next to a status pill:
On the right, the Force Math Exceptions box lets you override specific layers, such as base product cost or fulfillment cost, when you have hard evidence for a SKU that doesn't match the catalog default. Overrides are saved and treated as first-class inputs in the cost stack, not side notes in a spreadsheet.
Figure 1: Every cost layer carries a status pill. Evidence-backed layers are computed from real documents, Estimated layers come from a model, Mixed layers blend both, and Missing layers have no data yet. The Force Math Exceptions box lets you override a layer when you have hard evidence for a specific SKU.
Clicking an evidence-backed layer opens the Evidence & Model drawer. For fulfillment, you see:
This is the show-your-work layer. A founder, CFO, or auditor can see exactly which documents produced the number on screen and how the model turned them into a stable per-unit rate.
Figure 2: The evidence drawer for fulfillment. A 30-day rollup (133 units, $1,006.79) becomes a modeled $7.57 per unit, and every source document in the sample is listed by external ID, date, amount, and units. This is the number and the receipts on the same screen.
The integration panel (here, ShipStation via Direct API) shows where the evidence comes from and how fresh it is:
Figure 3: The integration panel shows connection status, last sync time, the live events that push new costs in real time, and exactly which data is synced. This is where the evidence chain starts, with read-only access that never modifies your ShipStation orders or settings.
Together, these three views turn "we think your fulfillment cost is about $7.57" into a traceable statement: here is the API that brings in every label, here are the raw ShipStation documents behind the number, here is how they were smoothed into a per-unit rate, and here is the badge that tells you this layer is evidence-backed, not guessed.
For brands that are raising capital, preparing for an acquisition, or bringing on a CFO, the ACTUAL vs ESTIMATED distinction stops being a dashboard preference and becomes a due diligence issue.
An acquirer or investor performing financial due diligence will want to reconcile your reported margins against your actual cost documents. If your profit tool has been using estimated shipping costs and estimated 3PL costs for 18 months, the gap between reported margin and actual margin may be material, and it will surface during diligence.
The more common and immediate version of this problem: you hire a fractional CFO or finance director, hand them access to the profit dashboard, and they ask where the numbers come from. If the answer is "some of it is real and some of it is estimates we set up two years ago," you've handed them a month of reconciliation work before they can do anything strategic.
Actual-vs-Estimated tagging is also a protection against internal decisions made with false confidence. A category manager who makes a SKU discontinuation decision based on an ESTIMATED margin that turns out to be 8 points too optimistic has made a different decision than if they'd known the number was estimated. Labeling doesn't slow decisions down. It makes them better calibrated.
A simple test: if your profit tool cannot show an auditor, on screen, the source document and methodology for a single order's margin calculation, assume every rolled-up margin chart will require manual reconciliation.
Before trusting any profit tool's margin numbers (including MarginOS), run it through these five questions. A vendor who can't answer them clearly is telling you something important about the confidence level of their data.
The right answer names a specific API, file format, or integration, not "we connect to Shopify." Shopify doesn't have carrier invoices or 3PL billing data. If the answer for shipping is "the shipping cost from the Shopify order," that's an estimated number based on what the customer paid for shipping, which may not equal what you paid the carrier.
Every tool makes assumptions when real data isn't available. The question is whether those assumptions are visible. If the answer is "we use a default you can customize," ask: how does a user know whether they're looking at the default or real data?
This is the drill-down test. If a tool can't trace any specific metric back to a source document or clearly named assumption, it can't be audited. That means you can't catch errors, and neither can anyone reviewing your financials.
A vendor who knows their product can answer this. "Our estimated shipping cost is within 8% of actual for brands using average box sizes" is an honest, useful answer. "Our numbers are very accurate" is not.
This tests data lineage. If COGS is updated in Shopify, does the profit tool retroactively recalculate margins for all affected orders, or does historical data remain stale? If historical data stays stale with no flag, every trend analysis you've done may be comparing apples to oranges.
MarginOS is built on the premise that showing a confident margin number without labeling its confidence level is more dangerous than showing an accurate margin number with an ESTIMATED tag. Every metric in the platform carries an explicit tag, a data source citation, and a methodology trace accessible in the UI.
When a real data source isn't yet connected, MarginOS shows an ESTIMATED metric with an amber badge, the assumption being used, and a prompt to connect the real data source to upgrade it. You always know what you're looking at.
This is how the full cost-layer model becomes actionable: each of the 8 layers starts as ESTIMATED when you connect and upgrades to ACTUAL as you wire in each data source. MarginOS shows you the upgrade path, so closing the gap between estimated and actual is a project with a clear to-do list, not an abstract data quality initiative. Once you trust the numbers, the LTGP:CAC model shows you what to do with them.
Actual-vs-estimated tagging only matters once you have a cost model worth trusting and a way to use it. The cost-layer model shows true contribution margin per SKU, and the LTGP:CAC model shows how far you can push paid acquisition on top of that. This data-quality framework sits between them: it tells you which profit numbers are safe to bet the business on, and which still need verification.
Sourced from a verified document or real-time API. Can be traced to a specific record.
Derived from a model, assumption, or average. Useful for direction. Verify before a high-stakes decision.
The source, assumption, and last-verified date for any metric. Turns an opaque number into an auditable one.
See actual-vs-estimated tagging in real time, not in spreadsheets.
Get your Profit & Inventory Command CenterOr email sales@marginos.com to see actual-vs-estimated tagging on your own data.
