Do orders, payments, refunds, and reported revenue agree?

Revenue reconciliation compares the commercial events recorded across order, payment, refund, fee, and finance systems. The objective is not another dashboard. It is an explainable record of why numbers differ, which source governs each decision, what remains unresolved, and how discrepancies will be monitored.

Open a Warrant | Read a Signed Case

One transaction can become several different numbers

An ecommerce order can be placed on one date, paid on another, partially refunded later, settled after fees, and reported differently by the commerce platform, payment gateway, finance system, and marketing dashboard.

Without an agreed reconciliation model, teams can make customer, channel, inventory, and investment decisions from numbers that describe different events.

Common symptoms include:

• order revenue and settled cash do not match;
• refunds appear late or in only one system;
• payment fees are missing from contribution reporting;
• failed, cancelled, or partially fulfilled orders are handled inconsistently;
• marketplace settlements cannot be traced back to order lines;
• finance and growth teams use different revenue definitions;
• dashboards silently change when source data is restated.

What Warranted examines

The commercial event model

What does the business mean by ordered, paid, fulfilled, returned, refunded, settled, recognized, and reported revenue? Which date and status govern each decision?

The source systems

Which systems create the order, payment, refund, fee, shipment, settlement, and accounting records? What are the stable keys, and where are they lost or transformed?

The reconciliation rules

How should timing differences, partial refunds, promotions, taxes, shipping, fees, chargebacks, cancellations, and foreign exchange be treated?

The exception path

Which variances are expected, which require investigation, who owns them, and how is a correction recorded without rewriting history?

A bounded revenue-reconciliation engagement

1. Name the commercial decision and the revenue definition it requires.
2. Map order, payment, refund, fee, settlement, and accounting sources.
3. Reconstruct a controlled period at transaction level.
4. Classify expected timing differences and true discrepancies.
5. Agree the governing rules, owners, thresholds, and exceptions.
6. Build or correct the reconciliation and reporting path.
7. Test the result against source records and known edge cases.
8. Document the remaining variance and the next decision.

What the client receives

• A commercial event and source-system map.
• An agreed revenue definition for the stated decision.
• Transaction-level reconciliation logic.
• A discrepancy taxonomy and owner path.
• A controlled baseline and validation sample.
• Monitoring definitions for new breaks or source drift.
• A written verdict that states what now reconciles and what does not.

How progress is measured

Measures can include reconciled-value percentage, unmatched transaction count, unexplained variance, time to investigate an exception, refund and fee coverage, settlement traceability, source freshness, and the commercial KPI that depended on the corrected record.

The target is not perfect-looking reporting. It is a dependable number with an explainable boundary.

Good fit

• Ecommerce, payment, marketplace, finance, or marketing systems report different revenue.
• Refunds, fees, settlements, or timing differences create material uncertainty.
• Teams need a dependable commercial view before changing spend, retention, pricing, or automation.
• Transaction-level records and accountable owners are available for review.

Not a fit

• The request is only to redesign a dashboard without resolving the source definitions.
• No one can approve the governing revenue definition.
• Source records cannot be accessed or sampled.
• The business requires a guaranteed financial outcome before reconciliation begins.

Questions buyers ask

What is revenue reconciliation?

Revenue reconciliation compares orders, payments, refunds, fees, settlements, and accounting records so the business can explain why systems differ and which number should govern a particular decision.

Why does ecommerce revenue differ between systems?

Systems often record different events on different dates. An order platform may show gross order value, a gateway may show settled cash after fees, and finance may apply recognition and refund rules. The difference is not always an error, but it must be classified and explained.

Is revenue reconciliation a finance or data project?

It is both. Finance owns important definitions and controls, while data and system teams implement the joins, transformations, monitoring, and exception handling. Growth and commercial teams define the decisions the reconciled view must support.

Does reconciliation require replacing our current tools?

Not by default. The first step is to identify whether the problem comes from definitions, identifiers, integration, transformation, timing, ownership, or platform limits. Replacement is one possible response, not the starting assumption.

What should a reconciliation dashboard show?

It should show the agreed number, source coverage, timing status, matched and unmatched value, discrepancy classes, owners, and unresolved limitations. It should not hide exceptions inside one total.

Decide what is warranted

Which revenue number is waiting for an explanation?

Open a Warrant | Read a Signed Case