Revenue Reconciliation: Stop the Manual GMV Grind

Executive Summary

---

How it starts: a single payment provider

I've seen this pattern often. In the early days of a marketplace, you launch with one payment provider, most likely Stripe. It's all very clean. The Stripe dashboard is your source of truth. Reconciling your bank deposits against your sales data is a straightforward, almost pleasant, task.

Your finance team can close the books quickly. Your GMV is a number everyone trusts because its source is singular and clear. This system works perfectly because its complexity matches the business's stage. It is simple, efficient, and, for a time, all you need.

But then you grow. And that's where the trouble usually starts.

The problem with adding more payment gateways

To make payments easier for customers and to expand internationally, you add more gateways. Perhaps Adyen for Europe, and PayPal because many people prefer it. Commercially, it's the right move. For the finance team, it's often the start of a recurring headache.

This is a common hurdle I see in businesses around the Series B stage.

The process today probably looks something like this:

Export a transaction CSV from Stripe.

Export another from Adyen, which will have different column names and fee structures.

Export a third from PayPal, which handles refunds and chargebacks in its own particular way.

Someone in finance, often one of your most experienced analysts, spends their week in Excel, trying to match transactions, standardise currencies, and normalise fee calculations across the different files.

You haven't invested in a modern data stack to manage your business on spreadsheets. But if the underlying process is broken, you're often just automating the creation of inconsistent data. The problem isn't the payment gateways themselves; it's that you don't have a Single Source of Truth for what a transaction is.

A more robust approach: treating financial data as a product

The only way I've seen this fixed for good is to stop treating Revenue Reconciliation as a manual accounting task and start treating it as an automated data product. The source of truth can't be a spreadsheet; it needs to be your data warehouse.

The solution, I'm afraid, requires a bit of focused work on the data architecture. It means building a dedicated transformation layer that does the hard work before a person ever sees the numbers.

Our approach is usually quite direct:

Centralise the raw data: We pull the raw, unaltered transaction logs from every payment gateway into your data warehouse, such as Snowflake or BigQuery.

Build a unified ledger: Using a tool like dbt, we build a series of data models that turn this raw data into a single, standardised transaction table. This model handles the messy work: de-duplication, currency conversion, fee calculation, and the consistent flagging of refunds and chargebacks. This is the core of a sound Data Strategy.

Codify business logic: The definition of GMV is no longer a topic for debate in a meeting; it's a line of code in a version-controlled dbt model. This ensures proper Data Integrity and provides an audit trail for every number.

By doing this, the process changes from reactive, manual work to something automated and governed. Your finance team can stop wrestling with data and start analysing the numbers, which are delivered to them, perfectly reconciled, every morning.

This isn't about a new dashboard. It's about rebuilding the data foundation so that all of your Financial Reporting is automated, auditable, and, most importantly, trusted.

The result: a three-day close

When the data architecture is right, the other problems tend to go away. The full-time reconciliation job is no longer needed. The month-end close often shrinks from two weeks to three days. Your CFO can go into board meetings with numbers they can defend without needing to open a spreadsheet.

This is a common outcome when a business treats its financial data with the same rigour as its customer-facing application. It's about moving on from patching the report to fixing the underlying data model.