Do your payouts add up? Automate reconciliation

Blocket, Klarna, or Tradera deposits a lump sum in the account. Nowhere does it say which orders the money covers, what fees the platform deducted, or whether a sale is missing entirely. Checking that by hand takes hours, so most people never do it, and missed money stays missed. This guide shows how AI does the check for you: every order is matched against every payout, every mismatch is flagged, and you approve before the books close.

The division of labor throughout this guide is simple: you export three files, the AI agent handles steps 1 through 6, and you make the decisions in step 7. You're reading this to understand what happens under the hood, not to sit with the files yourself.

Why doesn't the payout land on the same amount as your sales?

The payout differs from the sales because three separate sources describe the same transaction in three different ways: the platform's order export, your own order source, and the platform's payout report. Each has its own format, its own order key, and its own deductions. Reconciling them by hand takes hours every month and still misses mismatches a human doesn't have time to catch.

New to AI agents, start with our overview of AI agents for SMBs. Where reconciliation fits among the other e-commerce flows is covered in our article on AI agents for e-commerce.

In practice it often looks like this: an order has an order number you set yourself, for example in Shopify or WooCommerce. The payment provider, such as Klarna or Stripe, instead assigns its own reference number to the sale, and in the payout report the same order can be spread across several transaction rows. If you also sell through Blocket or Tradera, the same pattern repeats there, just under a third name for the same order. The formats each describe the same thing in their own language.

What do you need before you start?

You need three data sources per platform: the platform's order export, your internal order source, and the platform's payout report in CSV or PDF. Without all three, neither matching nor net calculation can happen, since each source only shows part of the picture.

If your orders are already gathered in one place, as covered in our guide to automating order handling, half the job is already done: the internal order source exists and updates continuously instead of being pieced together after the fact.

With several channels, such as your own webshop, Blocket, and Tradera, the whole protocol below runs per platform and finally rolls up into a single master table. Three sources times three platforms becomes nine files in a full monthly audit, not three – every platform has its own format, its own payout cadence, and its own exceptions.

Step 1: how do you collect the three sources?

First, every file you've collected is read and profiled: which columns it has, which data types, which fields can work as an ID, and what unit the amounts are in. It takes time now. The payoff comes later: once the rest of the protocol is built, you already know exactly what each source contains.

Three files, three formats

In practice, the files differ on almost every point:

• The platform's order export often has a reference number that doesn't resemble your own order number.
• The internal order source has the right order number but lacks the platform's internal transaction ID.
• The payout report lists transactions, not orders, sometimes several rows per order.

Profiling also reveals the amount unit. Some platforms report in minor units, where 229000 means SEK 2,290.00, meaning a division by 100 before anything else gets counted.

Why the internal source has to be row-level

The Swedish Tax Agency (Skatteverket) requires each sale to be booked individually, not just as a net sum from a payment provider. That's one reason the internal order source has to be row-level per order from the start, otherwise there's nothing to reconcile the master table's rows against in step 4.

If VAT, shipping, and discount sit in separate columns in the internal source but get merged into one sum at the platform, the internal file is what carries the level of detail you'll need later to explain a mismatch.

The same profiling also decides which fields qualify as an ID candidate. An order number reused across years, or a customer name spelled differently in two systems, looks like a key but doesn't hold up in practice.

Step 2: how do you build a shared order key?

Now a shared order key is built that works across all three sources, however different they look at the start. The key is normalized, for example by stripping prefixes and leading zeros, then tested against a real match rate before you move on.

A common approach is to let the internal order number be the source of truth and build a translation table against the platform's reference column and the payout's transaction ID. The table is built once per platform and reused every month, so the work isn't redone from scratch.

The match rate is the first receipt for whether the key holds up. If it's close to a hundred percent after the first test, the normalization caught the right fields. If it's lower, that's usually a sign a prefix, a hyphen variant, or an old order type hasn't been normalized away yet.

Example from a real monthly audit: at our client Telestore, which sells used phones through telestore.se, Blocket, and Tradera, the same order is called "WGR12345" internally but sits under the platform's own reference number in the order export, while the equivalent order on the next channel is instead called "#10123." A translation table built once per channel solved the matching.

Step 3: how do you normalize the amounts?

Next, every amount is normalized to a shared SEK standard, payout rows are grouped per order, and the net amount is calculated: sales minus fees minus returns. Without that step, figures in different formats and different currency notations can never be compared directly.

Minor units and separate rows

A common challenge when reconciling several channels is that a platform splits the payout into separate SALE, FEE, and RETURN rows per order, instead of a single sum. Settlement then becomes sales minus fees minus returns minus any tax, and all rows have to be grouped to the same order before the net can be calculated.

Klarna's own documentation for settlement reports shows the same principle from an established payout provider: each payment is broken down into transaction rows that together explain how the amount in the account became what it is.

Example from a real monthly audit: one of Telestore's three channels reports in exactly the minor-units format step 1 described, while also splitting every order into separate SALE, FEE, and RETURN rows. Without dividing by 100 and grouping the rows to the same order key, the net would have looked like it differed from both the order list and the payout, even though everything actually matched.

Thousand separators and direct deductions

Another common variant reports in English number format with thousand separators, for example "5,499.00," and deducts the platform's commission directly before payout: the amount paid out is gross minus commission, often with a monthly summary in PDF instead of row-level CSV. The exact commission rate varies by platform and agreement, so that figure has to come from your own payout report.

Step 4: how do you build the master table?

Everything is then gathered into a master table: one row per unique order key, with a flag for whether the order exists at each source, the amount from each, and match flags with notes.

A row can look like this in practice: the order key, exists_internally (yes/no), exists_at_platform (yes/no), exists_in_payout (yes/no), the amount from each source, and a match status column: green for a full match, yellow for an amount mismatch, red for the order being entirely missing from a source.

This is also the file you save. Every month the master table is exported as CSV, along with the six mismatch lists and an audit report in Markdown and Excel, so it can be opened, reviewed, and archived without anyone having to ask how it was built.

A master table that only shows "matches" or "doesn't match" isn't enough. It has to show exactly which source is off and by what amount, otherwise you're just moving the problem one step and calling it solved.

The advantage over comparing three spreadsheets by hand is that the master table is searchable and filterable. Want to see every order above a certain amount with no match, or every mismatch from a specific week? That's a filter, not an afternoon with three Excel tabs open side by side.

Step 5: what mismatch lists should the AI produce?

From the master table, AI then produces six mismatch lists – one for each type of gap that can appear between the three sources. Each list is a ready-made work list for a human, not raw material.

The six lists, one by one:

1. Exists internally but missing at the platform, often a sign an order never synced across at all.
2. Exists at the platform but missing internally, common with manual orders or an integration error that went silent.
3. Exists in the order lists but missing from the payout, for example an order waiting for the next payout period.
4. Exists in the payout but missing from the order lists, the kind of mismatch that hides easiest in a large file.
5. Amount differences, where the order exists everywhere but the sum doesn't match between sources.
6. Canceled or returned orders, which need their own check since they affect the net at several points at once.

A return that's deducted in the payout as a RETURN row, but never registered as a return internally, ends up in exactly the fourth list: exists in the payout but missing from the order lists.

Example from a real monthly audit: this is exactly the kind of finding Telestore's monthly audit is built to catch. A return the platform has already deducted but that was never registered internally lands in list four and is investigated before the books close, instead of surfacing months later as an unexplained difference.

How a return is registered correctly from the start, checked against the right of withdrawal and a store's own return policy, is covered in our guide to AI returns handling with a human in the loop.

Step 6: how do you verify the platform's totals?

The final arithmetic check covers the platform's own totals: sum the transaction rows yourself and compare against the platform's own summary, while verifying the settlement formula row by row. An error in the summing logic otherwise never shows up in a single order, only in the whole.

Bokio, a Swedish accounting platform, describes the same principle for bank reconciliation: if the sum in the books matches the balance in the account, the odds are high the rest matches too. Flip the order and rely only on the platform's own total, and you risk inheriting an error you never caught yourself.

FAR, the institute for the accountancy profession in Sweden, states in its guidance to BFNAR 2013:2 (a general recommendation from Sweden's Accounting Standards Board) that bookkeeping should be reconciled on an ongoing basis under fixed routines, with the frequency adjusted to the individual company's circumstances. For an e-commerce store with daily sales across several channels, that judgment almost always lands on monthly, or more often.

Automating reconciliation doesn't change that judgment, but it lowers the cost of doing it often. Bokio makes the same point in its own piece on why reconciliation should happen regularly: an error caught after a month is cheap to fix, the same error after a year can take consultant hours to untangle.

Step 7: where does the human come in?

Last comes the control chain: AI proposes and flags, the human approves. A clean match turns green and needs no decision. Every mismatch needs a human decision before the books close, and the AI never posts anything on its own.

In practice that means the system never writes a correction into the books. It presents the material and waits for an approval or an instruction. The run itself takes minutes. The human's job is to review the mismatch lists, not to hunt for them. Sweden's Bookkeeping Act (bokföringslagen, 1999:1078) places bookkeeping responsibility on the company, not on a tool, and that division of responsibility has to show in how the system is built, not just in a contract.

That's the core of how to automate reconciliation without giving up control: the machine does the tedious work of reading nine files and comparing them row by row. The human does the one thing AI should never do: take responsibility for the number that actually gets booked.

What tech stack do you need?

An automated reconciliation is built on three layers: a script layer that chews through the files, an AI agent that understands them, and a schedule that makes sure it actually happens every month.

Three layers, one by one

• Python and pandas read in the files, normalize order keys and amounts, and build the master table plus the six mismatch lists. It's the same tool whether the source is an Excel export, a CSV, or a PDF table that first needs extracting.
• An AI agent, for example built on Claude or another large language model, profiles new file formats automatically, writes the audit report's summary in plain language, and flags which mismatches look unusual compared with previous months.
• Scheduling runs the whole chain monthly, from collection to a finished report.

The output every month is the same regardless of tooling, ready to send on to whoever owns the books – whether that lands in Fortnox, Visma, or another accounting program. What a build like this usually costs, and when it pays off for your own volume, is in the cost guide for AI agents and in our savings calculator.

None of the three parts requires tearing anything existing down. Python and pandas run against the files you already export, the AI agent is added as a script in the same flow, and the scheduling is a cron line, not a new system to teach the whole team. It's the same pragmatic principle behind everything else we build: automate reconciliation on top of what already works.

Frequently asked questions