1 Why the amount paid almost never matches the invoice amount
Anyone running an online shop knows the pattern: the customer invoice says €119.00, but that amount never shows up on the business account. The reason lies in how payment service providers work. PayPal, Mollie, Stripe, Klarna, and Amazon Pay do not pay out per order but in batches – as a settlement or payout bundling dozens of transactions from a given period. Transaction fees are deducted before the payout. On top of that come refunds netted against new payments, partial payments, chargebacks, and – for international shops – currency conversion.
The result: the amount on the bank statement corresponds to no individual document.
Worked example: one PayPal payout
A customer orders for €119.00 gross. PayPal deducts the transaction fee right away – the merchant account is credited with roughly €116.20. The payout to the bank account, however, happens days later and bundles 37 orders: the sum of the credits, minus fees, minus two refunds from the previous week.
What lands on the bank statement is a single lump sum of, say, €4,187.53 – with no indication of which invoices it contains. That one amount has to be broken down in the accounting system into 37 open items, 37 fee postings, and 2 refunds.
2 How manual reconciliation works today – and why it fails
In many companies the process looks like this: once a month, someone exports the transaction reports from PayPal, Mollie, and Stripe as CSV. In Excel, the payments are lined up against the order numbers from the shop. Whatever matches gets posted manually in DATEV, Lexware Office, or sevDesk – payment against the open item, fee as an expense. Whatever does not match ends up in a leftovers column and waits.
With 50 orders a month this is annoying. With 500 or 5,000 it becomes a structural problem. The open-items list never fully balances because a residue of unresolved payments always remains. The month-end close is delayed because reconciliation waits for the last reports. The tax advisor receives documents with the payment assignment missing and asks questions. And the knowledge of how to read each provider's reports – which column holds the transaction ID, how PayPal flags refunds – usually sits with exactly one person. If they are out, reconciliation stops.
The manual approach does not scale with order volume. It does not get faster per order – only the Excel file gets longer.
3 Automated reconciliation: rules first
The good news: most of the reconciliation work is a rules problem, not an AI problem. All the providers mentioned offer APIs or settlement reports through which transaction and payout data can be retrieved automatically. A workflow – we build these with n8n – fetches this data at fixed intervals and matches it against the orders from the shop and the invoices from the accounting system.
Matching runs on hard references: the order number in the payment reference, the provider's transaction ID, or the combination of amount and date. Fees are split automatically – one payment turns into three posting components: gross amount against the open item, fee as an expense, payout amount to the bank account. The finished postings or documents then go via interface to DATEV, Lexware Office, sevDesk, easybill, or ADDISON – whichever system your accounting team or tax advisor works with.
| Typical case | How it is resolved automatically |
|---|---|
| Standard payment | Matched via order number or transaction ID; the payment is assigned to the open item and cleared. |
| Batch payout (settlement) | The provider's settlement report is broken down into individual transactions; each line is assigned to its order. |
| Transaction fees | Read per transaction from the report and posted as an expense to the appropriate fee account. |
| Refund | Recognized via the reference to the original transaction and assigned to the related invoice or credit note. |
| Chargeback | The reversal including the chargeback fee is recognized, assigned, and flagged for review – a case you want to look at anyway. |
4 Where AI makes the difference
With clean rules, in our experience 85 to 95 percent of payments can be matched automatically. What remains are the cases where rigid rules fail: prepayment bank transfers with a free-text reference ("March invoice Miller"), typos in the order number, partial payments and overpayments, payments with no reference at all, or the account holder having a different name than the customer – the wife paying her husband's invoice.
This is exactly where AI-assisted matching comes in. The model receives the payment record and the open items and suggests the most likely match – together with a confidence score. If the score is above a defined threshold, the match is applied and flagged as an AI suggestion. If it is below, the case goes onto a clarification list and a person decides. Human in the loop, in practical terms: the machine pre-sorts, and the final decision on unclear cases stays with your accounting team.
An honest note
The AI posts nothing blindly. Every match – whether by rule or by suggestion – is documented in a traceable way: which payment, which document, on what basis. Edge cases are confirmed, not guessed. And: classic automation resolves the majority of cases more reliably and at lower cost than any language model. AI is added deliberately where rules stop working.
5 How we implement this
A payment reconciliation project runs in four steps with us. First, we map the payment flows: which providers are in use, what do their reports look like, where should the postings go? Then we define the matching rules and the confidence thresholds for the AI suggestions – together with your accounting team, because that is where the knowledge about the special cases lives. Next, we build the workflow and test it against real historical data before it goes live. In operation, monitoring watches the runs and reports when a provider changes its report format or an interface acts up.
On request, the workflows run self-hosted with n8n on your own server – your payment and customer data then never leaves your infrastructure, which considerably simplifies the GDPR assessment. You can find more on our approach under e-commerce automation; how such data flows are set up cleanly on the architecture side is covered in our article middleware for SMEs. Data automation beyond the shop – across the whole company – is bundled under our brand ec data.