Scott — this is me making sure I fully understand the cost-cleanup idea from our Nov 11 call before I decide (1) whether to build it and (2) how it should work. I've written up the concept, the dynamics, and the competitive picture as I see them. Where I've got it wrong or thin, push back — the questions for you are at the end.
Cleaning up costs is the means; the goal is a trusted, audit-defensible starting point for inventory value & COGS. But there's a real scoping tension I want your gut-check on: a lot of sellers may only need a good opening balance, not a full reconstruction of the past (§7). So the build question is really "how big is the segment that genuinely needs the past fixed?"
Both — but reframe it. The feature recomputes accurate landed cost & COGS from a customer's history, but cleaning costs is just the lever. The actual purpose is to manufacture trust: e-commerce sellers who've been on moving-average cost (or just did it wrong for years) don't believe their own financials. This gives them — and their accountant — numbers they can stand behind, and it gives SKU a correct foundation to post accounting forward.
Yes. This is fundamentally an onboarding / migration exercise. It ingests pre-SKU history — primarily purchase orders + landed costs and period-end inventory balances — and replays it through SKU's costing engine. You named the two pillars exactly: purchase orders and ending inventory balances.
End result (the deliverable): a rebuilt FIFO cost ledger → accurate inventory valuation & COGS per period, a change summary (CSV), and an "accounting report" of ins/outs + per-month adjustments the customer hands to their accountant to true-up their books.
End goal (the why): make SKU the single trusted source of truth for inventory accounting — which is the precondition for everything Scott wants on top: asking questions of the data, demand planning, real profitability analysis.
Scott's framing: when a seller comes to SKU, their cost history is almost always broken in one of two ways.
A single blended unit cost that re-averages on every receipt. It smooths over cost spikes — which feels nice until tariffs hit.
With tariff wars & volatile freight, a late duty bill silently re-blends the average going forward and misstates the margin on units already sold. You can't see which sales actually carried the tariff. Scott: "if you're not on FIFO with tariff wars… you have to go back."
POs entered wrong, costs missing, landed costs ignored, books a mess.
Result: inventory quantities, landed cost and COGS are all untrustworthy. Scott had a seller who "totally didn't trust their financials." Without a clean base, nothing downstream (margins, forecasting, valuation for a sale/exit) can be believed.
Either way the customer arrives with contaminated history. The feature exists to hand them back a clean one — and to make SKU the system that keeps it clean.
Two paths to the same destination, depending on how much history the customer actually has.
If the customer's full event history is in SKU (or importable), SKU replays every event from the beginning — receipts, transfers, sales — and re-derives the entire FIFO layer flow. Kalvin: "it does the whole thing from the initial events… fix all those errors for the past four, five years all in one shot." Ends with an on-screen summary + downloadable CSV of every COGS change.
When they don't have full event history, import POs + month-end balances. SKU "manufactures" a stock-take each month that performs the implied usage (negative) events, establishes the FIFO usages, and recomputes COGS + inventory value per month — then cross-checks against their old numbers and flags adjustments.
Scott's one-line test: "You just need one starting point — what they purchased on a purchase order and landed costs — and then you can figure it all out." In practice it's three pillars + a comparison baseline.
"POs are the great source of truth for establishing COGS." This is the non-negotiable input.
These become reconciliation anchor points that catch drift between the rebuilt layers and physical reality.
"What we thought was the truth" — the before, so SKU can compute the delta to fix.
Historical Shopify / Amazon sales & fulfillment Warehouse mapping
Pulling in real sales shows how fast they shipped and can prove their month-ends were off. The hard part: in a multi-warehouse setup, SKU doesn't know which warehouse historically fulfilled each order — so events need warehouse mapping, or you keep it simple and reconstruct usage purely from POs + month-end counts (single-warehouse is trivial; multi needs mapping).
Rebuilt FIFO layers → accurate inventory valuation and COGS per period. SKU becomes the source of truth for the inventory asset account going forward.
On-screen + downloadable summary of every COGS change and the items impacted — old vs new. The audit trail of what the rebuild did.
The headline deliverable. A report of ins / outs + per-month adjustments that the customer hands to their accountant, who posts the adjustments into the financials. Scott: "that'd be huge… give it to their accountants and they post the adjustments."
Where reconstructed numbers don't reconcile to the old ones: "you have 50,000 units disappear — where'd they go?" Turns a cleanup into a diagnostic.
Late in the call Scott laid out the whole stack. Cost cleanup is step 1 — without it, nothing above it is trustworthy. This is also the thread that connects to the "let users analyze their accounting data in SKU" idea you remembered.
Scott: "Every e-commerce business is a data business." The cleanup isn't an accounting chore — it's the foundation that makes SKU's analytics, reporting and forecasting believable.
This is the most important design constraint Scott repeated — and it's where the incumbents fail.
DEAR / Cin7 Core re-pushes a flood of historical journal entries into Xero/QBO — and if you unlock a closed period to fix something, it "dumps all this crap." Scott: "Deer was the worst." It corrupts closed periods and breaks reconciliations. SKU must never blindly dump transaction-level history into the accounting system.
Compute what the inventory/COGS accounts should be, compare to what's posted, and produce summarized per-period adjustments. The accountant decides how to book them — spread per month, or one true-up journal entry. This is exactly how Scott fixed a seller's books with A2X: set up a separate account, reconcile, "do the math for a journal entry to fix their income."
Accounting terms for this, if useful: opening balances, adjusting journal entry (AJE), prior-period adjustment, inventory-to-GL reconciliation, retained-earnings true-up. The universal pattern is "book one summarized entry for the difference — don't re-key every transaction."
Scott — this is the section I most want your read on, because it's the heart of the build decision. There's a much cheaper alternative to reconstruction, and for a lot of sellers it's good enough. So the real question isn't "can we build it" — it's "how big is the segment that genuinely needs the past fixed?"
Physical count at cutover → assign a reasonable cost per unit → that's your opening inventory layer → move forward. This is the standard migration default (it's literally what Cin7/DEAR do). And there's a second self-healing effect on top of it:
Problem A — be accurate going forward.
Solved by opening balance + turnover. No reconstruction required. ✓
Problem B — trust / correct the past.
Only the full reconstruction solves this. Opening balance throws the past away.
The whole value of the reconstruction feature lives in Problem B. So the build case rests entirely on: how many sellers have a real reason to fix the past? (exit/sale due diligence, raising debt/equity, tax restatement, tariff-broke-the-averages, or simply "I don't trust my financials" — Scott's seller).
| Just set an opening balance (cheap) | Do the full reconstruction (the feature) |
|---|---|
| Fast, uniform inventory turns | Slow turns / lots of dead stock → error persists for years |
| They know their costs well enough to value opening stock | Costs are unknown/garbage → reconstruct from POs to derive a trustworthy cost |
| Nobody relies on the historical financials | Exit / sale, fundraising, lender, or tax restatement needs clean history |
| Costing wasn't distorted | Tariffs retroactively broke moving-average (Scott's trigger) |
| "Move forward, don't look back" | Founder explicitly doesn't trust their numbers |
These aren't strictly either/or. When a seller can't even tell you "roughly what the goods cost," the historical PO reconstruction is how you derive a trustworthy opening cost — even if they don't care about fixing the past. That suggests a staged build: v1 = "smart opening balance" (use PO history to compute an accurate opening cost basis — broad appeal, lower effort), v2 = "fix the past" (the full per-period adjustment report — premium, for the exit/tariff/distrust segment). Scott — does that segmentation match what you see in the market?
Scott name-dropped several. Here's what they actually do for historical cost cleanup, and where SKU sits. The big takeaway: almost nobody rebuilds FIFO COGS from origin — they migrate balances or post forward.
| Tool | What it is | Retroactive cleanup? | Costing | Notes for us |
|---|---|---|---|---|
| SKU.io | Full IMS w/ inventory accounting (v2 ledger) | Yes — rebuild from origin | FIFO (real layers) | Replays full movement history → re-derives layered COGS; produces change CSV + accountant adjustments. The differentiator: does what incumbents punt on. |
| SellerVue | Landed-cost / COGS software for Amazon sellers | Backfill, not reconstruct | Landed cost | The "seller view" Scott meant. Self-serve; computes true per-unit landed cost (factory+freight+duty+tariff). Forward-accuracy, not a fix-the-past engine. Markets to exit/acquisition prep. |
| Finaloop | Real-time bookkeeping (software + human team) | Yes — explicit catch-up | Avg default; FIFO landed (InventoryIQ) | Closest "software does retroactive cleanup." Bulk-edit historical unit cost → recompute prior COGS. But it's a books product, not an IMS. ~$245–995/mo + per-month catch-up fees. |
| A2X | Channel settlement → accounting summarizer | Catch-up + reconcile delta | $ COGS only (no units) | The model for "post the delta." Splits sales/fees/COGS by channel via Xero tracking categories; debit COGS / credit inventory. Tracks dollar values, NOT unit quantities — not a real IMS. $29–~$1,000/mo. |
| Settle | AP + procurement + landed cost | No — prospective | Landed cost (nightly recalc) | Recalculates landed cost as bills arrive; posts JEs via A2X. Forward-looking. ~$199/mo. |
| Cin7 Core / DEAR | Inventory ERP (sub-ledger → Xero/QBO) | Constrained; floods GL | FIFO actual cost | Migrates balances, not history. Back-dated changes are gated; unlocking a period + "load historical data" re-dumps journals. The anti-pattern to avoid. |
| Finale Inventory | Inventory management | Back-dated cost change | Weighted average | Supports a back-dated "Average Cost Change" to retroactively fix costs — but average, not FIFO layers. Proof the demand is real. |
| Ordoro · Linnworks/SkuVault | OMS / WMS-lite | Manual only | Moving average | No automated retroactive recompute; cost corrections are manual/CSV. COGS depth offloaded to the accounting system. |
| Done-for-you firms | LedgerGurus, Bean Ninjas, EcomBalance, Acuity / Catching Clouds | Yes — by hand | Manual | This is Scott's "pay a couple grand and they clean it up." ~$500–2,000 per messy month; inventory adds $300–1,500/mo. SKU automates what they bill hourly for. |
| NetSuite · ApparelMagic · ChannelAdvisor | Enterprise ERP / channel mgmt | Gated, consultant-only | FIFO/LIFO/Avg | Why Scott says "avoid like the plague": 4–6 month implementations, $75K–200K fees, multi-year contracts. The heavyweight end SKU undercuts. |
The market splits into forward-accurate software (SellerVue, Settle, Bookkeep) and human cleanup services (LedgerGurus, Bean Ninjas… and the couple-grand crowd). The middle — a system that automatically rebuilds accurate FIFO COGS from origin (POs + month-end counts) and emits accountant-ready adjustments — is essentially empty. Finaloop comes closest but it's a books product, not an IMS. That gap is the feature's wedge: it makes onboarding a sales weapon ("give me your data → here's your corrected historical report → now sign").
These map to the two things I'm trying to decide. Strategic ones tell me whether to build it; design ones tell me how it should work. Your gut on the strategic block matters most.