How we make a growth platform agree with the ERP before it steers purchasing

A growing distributor soon works with two sources of truth: the ERP, and the dashboards and tools built around it. As long as both show the same figures, decisions move fast.

When they disagree, growth slows down. A reorder waits while two spreadsheets are compared, and a channel decision stalls in a meeting about which figure is right.

So every operating platform we build on an ERP has to agree with the ERP, month by month, before anyone uses it for a decision. Only then do forecasts and reorder lists run on it each morning.

Two things we put in place before the platform steers a reorder.

• Trust
  Month-by-month audit against the ERP’s database
  counts and amounts per document type
  Differences show up before anyone uses the figure

  Before

  none

  After

  in place, runs daily

• Trust
  Products with a forecast, across reloads
  found and fixed in our review
  Forecasts hold across reloads

  Before

  unstable

  After

  stable, matches the backend

The dashboard that disagreed with itself

On one reload, our forecast page showed 89 products with a forecast, and on the next it showed 210. Our review traced the jump to how the page loaded its data.

The cause was two quiet limits in the database behind the dashboard. It returns at most 1,000 rows per request, which means large tables load in pages, and without a fixed sort order each reload could receive a different mix of rows. That produced the 89 and the 210, and the fix made the count stable.

A second query asked for the whole product table at once, silently received only the first 1,000 rows and showed 141.

We fixed both on every affected page. Each paged request now has a stable sort order and every large table is read in pages. The page now shows the same number as the backend on every reload.

A dashboard that disagrees with its own backend can do more harm than having none. It undermines trust in the numbers that are correct, and that trust is what makes decisions fast.

The commercial question

A business that sells through its own shop, Amazon and business customers makes the same decisions every week. It decides what to reorder, what to send to Amazon’s warehouses, where to hold the price and which channel gets the next euro.

Each of those decisions builds on a number and scales up any error in it. If the sales figure per product is overstated, the reorder comes out too large and cash sits in the warehouse. If it is understated, the product runs out and the listing loses ground. Steering needs one checked figure per product and channel, and it needs that figure on the morning of the decision.

Why the ERP became the referee

Spreadsheets and automation flows that get patched by hand cost nothing up front, yet they take team time every month and surface silent errors only by chance. A dashboard tool on the ERP’s exports is quick to start. Its figures are only as good as the export, which can calculate some documents differently from the ERP’s own database.

A thin owned layer on the ERP takes weeks to build and needs upkeep. It reads the database itself, though, so the ERP becomes the referee, checks run daily, and forecasts and reorders sit on the same base.

The platform reads the ERP read-only and cannot change a record, and for every figure the ERP remains the master record. The sync jobs run on the client’s own server. The mirror sits in a hosted database that only signed-in users can read.

The mirror keeps a few customer fields per order: name, email, city, country and VAT ID. Street addresses and phone numbers stay in the ERP, and the Amazon reports we read contain no buyer details.

The check design

Revenue in an ERP rests on three document types: orders, invoices and credit notes. For each type and each month, we compare counts, line positions and net amounts with the ERP’s own database. That gives a small matrix of month-checks, and every cell must agree with the ERP before the figures carry a decision.

The figure shows the layout of the checks, not a dated record. Its amber cells mark a flagged month, like the missing credit note described under Guardrails.

Behind the matrix sits a small data model. Each month-check sums the ERP documents and their mirror records for one type, month and measure. It stores both values, the delta and a status. Counts must match exactly. Amount totals may differ only by rounding, and the audit flags any gap above one euro. We keep that allowance fixed rather than scaling it with volume. A busy month is therefore flagged sooner.

The checksum line on each page is a separate, coarser layer. It compares a page’s displayed total with the platform’s own database and flags a deviation above one percent. It is aimed at display faults such as the paging issue above, while the one-euro audit guards the platform against the ERP.

Orders, not invoices, are the revenue basis, because orders carry the sales platform, destination country and customer type that channel decisions need. Order revenue is a steering figure, not booked revenue. Invoices and credit notes stay in the same audit, so the booked side is checked as well. Each document type is compared only with its own counterpart in the ERP. An order and its invoice can therefore fall in different months without creating a gap.

The audit proves that the mirror matches the ERP. It does not prove that the ERP matches the money. For Amazon, fees and adjustments sit in Amazon’s settlement reports, and checking the ERP against those is a separate reconciliation that this audit does not cover.

Common ways revenue gets overstated

Most reconciliation gaps come from a handful of patterns. None of them breaks a row count. That is why they survive.

• Quotes in the order table. Many ERPs keep quotes and orders in one table. A sync that does not separate them inflates revenue while every row is real.
• List price instead of charged price. Where business customers get discounts, storing the list price inflates their revenue in particular. We check the charged price.
• Refunds filtered by prefix. A filter that looks only at number prefixes can drop a class of refunds. Every refund type needs its own check.
• Foreign currency read as euros. Orders in other currencies must pass through the ERP’s exchange-rate factor before they count.
• Orders without a product link. They fall into an “unknown” bucket unless a rule assigns them, for example by sales platform.

Each pattern becomes a gate on the way from an ERP document to the figure on a dashboard.

The loop

We run the same loop for every source and every document type.

1. Mirror. Sync the ERP read-only into the platform.
2. Compare. Check count and amount month by month against the ERP’s database.
3. Explain. Trace each gap to the documents that cause it.
4. Fix the rule. Correct the sync or the view, never the report.
5. Re-run. Repeat the comparison until the gap is down to rounding.
6. Lock in. Add a check so that the gap cannot return unnoticed.
7. Build on it. Only then use the figure for forecasts, reorders or pricing.

Steps three and six carry the method. We explain a gap before we fix it, and we keep a fix only when a check guards it.

What a wrong number costs

A wrong figure costs money before anyone notices it. Reorders follow demand, and an overstated demand figure makes every purchase order buy too much.

In this sketch, a 2 percent error ties up at most about €2,000 per €100,000 of purchasing. Real reorder logic nets out stock on hand and safety stock, and the true figure is usually lower. Counting quotes as sales can inflate the demand figure far more. Whether the build pays off depends on purchasing volume and on how large the gap is. So the first step is to measure the gap.

Guardrails

The audit showed its value later, when a re-run found one credit note missing. The audit named the document, so the fix was a wider sync window, not a search. For us, reconciliation is a practice we keep running rather than a number we print once.

What it unlocks

A reconciled base earns nothing on its own. It is the base we put forecasts, reorders and pricing on.

On the same base, forecasts, reorder lists and FBA send quantities can run every morning. A price watch can use the business’s own listing prices as the reference, next to the Buy Box share from Amazon’s own sales and traffic report.

Margins come next, and before they drive decisions, cost prices, reference prices and lead times have to be complete. When they are, we re-verify every margin view with the same loop. The morning run can then show what earns money, not only what sells.

Before your next dashboard

1. Reconcile before you optimise. A growth decision is only as good as the number under it.
2. Let the ERP’s own database be the referee. Exports and reports can calculate some documents differently.
3. A check that keeps running beats a perfect number once. Gaps appear after go-live too.
4. Show coverage next to every figure. A margin to the cent means little when the cost field under it is empty.
5. Build the smallest owned layer that answers the question. Keep the ERP as the master.

Pick one month and compare the revenue in your ERP with the revenue in your reports. If the two differ, that difference is the first thing we would trace with you.

Credits

Built by the Capcelerate team. Thanks to the client’s team for access and time.