Appearance
How the Math Works
Ordara keeps two kinds of record, and the difference explains most of this page.
What you and your email give it is stored: which order line items belong to which product, and a dated ledger of your sales and adjustments. Every summary figure — ordered, delivered, on hand, sold, revenue, cost per unit, profit — is derived from those, recomputed on the fly. None is editable directly; you change them by changing the entries underneath, correcting a wrong one by deleting it and recording it again.
Two things are captured onto a transaction and then left alone. The fee in dollars is frozen the moment you save the sale, always. The unit cost freezes as soon as Ordara has a cost worth freezing — usually the same moment, but a transaction it cannot value yet stays open until the product qualifies. Both exist to stop a preset you edit later, or a restock at a new price, from rewriting profit you have already reviewed.
The result: no figure drifts without a reason you can point at, and any figure you disagree with traces back to the orders, sales and adjustments that produced it.
The one rule that explains everything else
Ordara never edits your parsed order data. Corrections are recorded alongside it — as overrides, or as new entries in a log — so the original email-derived record stays intact and re-syncing is always safe.
The quantity metrics
| Metric | How it is calculated |
|---|---|
| Ordered | Every unit on the order lines linked to this product |
| Delivered | The units those orders have actually delivered |
| Sold | Every unit across the sales you have recorded |
| Adjustments | The running total of your quantity corrections (positive and negative) |
| On hand | Delivered − Sold + Adjustments |
| Unsold | Ordered − Sold |
On hand is what you physically have right now. Unsold is what you have not sold yet, whether or not it has arrived. The two differ whenever either is true: some of what you ordered has not been delivered, or you have recorded adjustments that changed what is on the shelf without changing what is still yours to sell.
Cancelled units drop out
Cancellation is counted per unit, not per order. A whole-order cancellation removes every one of that order's lines from the metrics above. A line-level cancellation — the retailer cancels one item and ships the rest — removes only the cancelled units and leaves the survivors counted in full.
Either way, that product's Ordered, Delivered, and cost figures decrease when the cancellation lands. The Orders tab shows the split as "N kept" over "M cancelled" on the affected line. See Accuracy & Limitations.
How "Delivered" is determined
For each linked order line, Ordara takes the greater of two figures:
- The quantity marked delivered on that line's shipments, and
- The line's full quantity, if the order as a whole is marked delivered.
The second rule exists because many retailers announce delivery for the whole order without breaking it down per item. Without it, those lines would read as zero delivered and your on-hand count would be far too low.
The result is then capped at the line's surviving quantity, so a line can never report more delivered than it has units. One order line can legitimately appear on more than one shipment record — a shipping email with no usable item breakdown gets the whole order attached — and without the cap a two-unit line covered by two such shipments counted four delivered. The cap respects a quantity override, so correcting a mis-parsed quantity corrects the delivered figure too.
WARNING
A partial delivery from a retailer that does not itemize will still count as fully delivered, up to the line's quantity. If your on-hand count runs high for a specific retailer, this is usually why.
The money metrics
| Metric | How it is calculated |
|---|---|
| Cost/Unit | total cost ÷ the units Ordara has a price for — a weighted average. Units whose price never arrived are left out of both sides, so they neither raise nor lower it |
| Revenue | quantity × price per unit, summed across your recorded sales |
| COGS (cost of goods sold) | Each sale's units × the cost frozen onto that sale, summed. Sales without a frozen cost fall back to the current Cost/Unit |
| Fees | The fees attached to those sales |
| Profit | Revenue − COGS − Fees |
Write-offs are deliberately absent from Profit: a damaged unit is a loss on inventory, not a loss on a sale. They appear on the portfolio Profit / Loss card and on Profit & Loss Reports instead.
When no priced purchase is left behind a product — every order behind it cancelled, say — Cost/Unit is $0.00. Any units still valued at that missing cost therefore contribute nothing to COGS, and that much of Profit is really just revenue minus fees. Rather than let it pass as a margin, the app labels the product No cost basis wherever Cost/Unit appears.
Units already frozen at a real cost keep it and are unaffected, so a product can carry the label and a perfectly real COGS at the same time. See Accuracy & Limitations.
Weighted-average cost
If you bought the same product at different prices, Ordara blends them into a single cost per unit rather than tracking each purchase as its own lot:
60 units @ $20.00 = $1,200
40 units @ $25.00 = $1,000
─────────────────────────────
100 units = $2,200
$2,200 ÷ 100 units = $22.00 per unitEvery unit of that product is now valued at $22.00, whichever purchase it physically came from — this is weighted-average costing. (It is the same product used in the worked example below.) Ordara does not do FIFO (first-in-first-out) lot tracking — it does not try to remember which particular purchase a sold unit came from. See Accuracy & Limitations.
Cost is frozen onto each sale
The weighted average moves whenever you buy more of a product. To stop that from rewriting profit you have already reviewed, Ordara freezes the cost onto the transaction — normally as you record it. A sale frozen when the average stood at $22.00 is costed at $22.00 forever, even after a restock moves the average to $30.00. Write-offs work the same way.
Freezing needs a cost worth freezing, so it happens only when all three are true:
- at least one of the product's purchases carries a price Ordara can use,
- none of its lines came through without a price, and
- none of its order lines are sitting in Needs review.
The middle one is why an unpriced line matters: it does not distort the average, it postpones it. Nothing freezes against a basis still missing a piece.
A transaction that misses any of the three is left provisional, valued at the product's current average — a figure that keeps moving. Ordara freezes it retroactively once the product qualifies: a new order landing, a cost you override, a review you clear, a merge or a split. Freezing only fills a blank; an already-frozen cost never changes.
What "frozen" does and does not mean
The frozen figure is the average as it stood when the transaction was recorded — or, for older ones, when Ordara first had a complete basis. It is not the cost on the day those units were bought. Ordara does not reconstruct historical cost; it stops the figure drifting from here on. See Accuracy & Limitations.
How fees are applied
A percentage fee is calculated against that sale's revenue at the moment you record it, and the resulting dollar amount is frozen onto the sale.
20 units @ $40.00 = $800.00 revenue
eBay 10% = $80.00 fee ← stored as $80.00, not as "10%"Editing or deleting the fee preset later has no effect on sales you already recorded. Your historical profit figures never move under you.
The two ledgers

The right-hand rail on a product page shows the same two equations, always visible:
On-hand reconciliation
| Line | Units |
|---|---|
| Delivered | 100 |
| Sold | −30 |
| Adjustments | −7 |
| On hand | 63 |
Profit
| Line | Amount |
|---|---|
| Revenue | $1,300.00 |
| Cost of goods sold | −$660.00 |
| Fees | −$80.00 |
| Net profit | $560.00 |
A worked example, end to end
One product, bought twice, sold twice, with two damaged units and one count correction.
Purchases
| Order | Units | Price / unit | Line cost |
|---|---|---|---|
| Walmart | 60 | $20.00 | $1,200.00 |
| Target | 40 | $25.00 | $1,000.00 |
| Total | 100 | $22.00 weighted avg | $2,200.00 |
Sales
| Date | Channel | Units | Price / unit | Revenue | Fee |
|---|---|---|---|---|---|
| Apr 10 | eBay | 20 | $40.00 | $800.00 | $80.00 |
| May 5 | TCGplayer | 10 | $50.00 | $500.00 | — |
| Total | 30 | $1,300.00 | $80.00 |
Adjustments
| Date | Change | Reason |
|---|---|---|
| May 20 | −2 | Damaged |
| May 21 | −5 | Count correction |
The resulting figures
| Metric | Value | How |
|---|---|---|
| Ordered | 100 | |
| Delivered | 100 | |
| Sold | 30 | |
| Adjustments | −7 | −2 damaged, −5 count correction |
| On hand | 63 | 100 − 30 − 7 |
| Unsold | 70 | 100 − 30 |
| Cost/Unit | $22.00 | $2,200 ÷ 100 |
| Revenue | $1,300.00 | |
| COGS | $660.00 | 30 sold × $22.00 |
| Fees | $80.00 | |
| Profit | $560.00 | $1,300 − $660 − $80 |
The same period as a Profit & Loss statement — which additionally charges the damaged units as an expense, and deliberately ignores the count correction:
| Line | Amount | Margin |
|---|---|---|
| Revenue | $1,300.00 | |
| Cost of goods sold | −$660.00 | |
| Gross profit | $640.00 | 49.2% |
| Selling fees | −$80.00 | |
| Shrinkage | −$44.00 | |
| Net profit | $516.00 | 39.7% |
Shrinkage is the accounting term for inventory you lost rather than sold — damaged, or lost and stolen. Ordara values it at cost and charges it as an expense in the period you recorded the adjustment.
The 5 corrected units are not an expense. A count correction means your records were wrong, not that you lost anything. See Profit & Loss Reports.
Three profit figures, two formulas
The product page's Profit ($560.00) is the only one that leaves write-offs out. The portfolio Profit / Loss card ($516.00) and this statement's Net profit ($516.00) both charge them, so the card and a statement covering all of your history agree by construction.
Where to go next
- Profit & Loss Reports — the realized income statement and its accounting basis
- Accuracy & Limitations — every approximation in the figures above, and what it means
