Payment Reconciliation: Match Payments with the ERP
Every payment in e-commerce ultimately has to find its way into accounting -- and that is exactly where the greatest manual effort often arises. Payment providers pay out in bundles, deduct fees, offset chargebacks and truncate reference numbers. The result is a mountain of payouts that cannot be matched one-to-one to the orders and invoices in the ERP. Chargebacks alone cause global costs of around 33.79 billion US dollars in 2025 (Juniper Research, 2025), and merchants tie up an average of around 10 percent of their revenue in combating payment fraud (Chargeflow, 2025). Automated payment reconciliation matches payouts, orders and invoices rule-based and hands the result cleanly to DATEV or your ERP system. This article shows how a reliable reconciliation works technically -- from matching logic through fees and chargebacks to the API-based posting.
Key takeaways
- Payment reconciliation matches the actual cash flows from payment providers against orders and open items and hands the result cleanly to DATEV or the ERP.
- The matching engine works in stages, from the exact hit through amount matching with tolerance to the grouped comparison of bulk payouts.
- Fees belong in a gross-net split: the receivable is settled in full, the provider fee is posted separately to an expense account.
- Chargebacks are assigned to the original transaction, the receivable reopened and the reversal fee captured separately.
- Items that cannot be assigned uniquely land in an exception list instead of a forced posting -- this keeps the automatic share reliable.
Why Payment Reconciliation in E-Commerce Is So Difficult
In brick-and-mortar retail, reconciliation was simple: what was in the till got posted. In e-commerce, however, several stations lie between order and incoming payment. The customer pays today, the payment provider collects the money tomorrow and transfers it in bulk to the business account the day after -- minus fees, minus any offset reversals, and with its own payout reference that no longer has anything to do with the original order number.
Add to this the variety of payment methods. Purchase on invoice remains one of the most popular payment methods in German online retail with a 25.8 percent market share (bevh, 2025), and in B2B even 95 percent of buyers want to purchase on invoice, while only 45 percent of merchants offer this option (Mondu, 2025). Purchase on invoice, however, means open items, partial payments, dunning levels and late incoming payment -- a reconciliation scenario that differs fundamentally from instant card payment.
Manual reconciliation eats up time and is error-prone. In projects we regularly see accounting teams spend several hours per week just assigning bulk payouts (project experience). Every incorrectly assigned payment creates a difference amount that has to be laboriously researched later. The indirect process costs of payment processing also carry weight, because handling and reconciliation tie up time (ibi research, 2025). This is precisely where an automated interface solution comes in.
Bulk Payouts
Providers pay out many transactions in a single amount. This has to be resolved back into individual orders and invoices.
Fee Deduction
Transaction, discount and exchange rate fees reduce the payout amount -- the difference has to be posted as an expense.
Chargebacks and Reversals
Reversals are often offset against the next payout and appear as negative items without any order reference.
Time Lag
Days lie between order, collection and payout. The incoming payment belongs, in accounting terms, to an earlier period.
Truncated References
Payment reference texts are often shortened to a few characters, so unique assignment via the reference does not succeed in every case.
Multi-Channel and Currencies
Sales across multiple channels and in foreign currencies significantly increase the number of source systems and special cases.
The Three Data Sources: Payouts, Orders, Invoices
A reliable reconciliation begins with the clean capture of three data sources. First, the payouts from the payment providers: payout files or API reports that list each transaction with gross amount, fee, net amount, payout date and a transaction ID. Second, the orders from the shop system, ideally via webhook or API including order number, amount, payment method and status. Third, the invoices and open items from the ERP or DATEV, representing the accounting target state.
The art lies in connecting these three worlds via common keys. In practice, these are usually the order or invoice number as the primary key, the amount as a secondary criterion and the date as a tolerance window. A middleware normalizes the different data formats before the actual reconciliation begins -- because every provider delivers its reports in its own schema, with its own field names and its own fee logic.
Clean Master Data Is the Prerequisite
Matching Logic: From Exact Hit to Fuzzy Assignment
The heart of reconciliation is the matching engine. It works in several stages, from strict to tolerant matching. The first stage is exact matching: the reference number matches and the amount fits to the cent. These cases can be posted fully automatically and without risk. In well-maintained setups, this procedure alone covers a large part of the transactions.
The second stage is amount matching with tolerance: if the reference is missing or truncated, the engine searches for open items with a matching amount within a date window. To avoid incorrect assignments, a hit is only accepted if it is unique -- if there are several candidates with an identical amount, the case lands in the exception list. The third stage is grouped matching for bulk payouts, where the sum of many individual items is checked against a payout amount.
The clean handling of cases that cannot be assigned automatically is decisive. Instead of forcing them, they are marked as unmatched and provided in an exception list. This keeps the automatic share reliable, and the accountant deals specifically only with the real exceptions. In practice, auto-match rates of well over 90 percent can be achieved (project experience) if reference handling and mapping are right.
def match_payout(payout, open_items):
# Stage 1: exact reference + amount
for item in open_items:
if item.ref == payout.ref and item.amount == payout.gross:
return Match(item, payout, level="exact")
# Stage 2: amount + date window, only if unique
candidates = [i for i in open_items
if abs(i.amount - payout.gross) < 0.01
and within_days(i.date, payout.date, 7)]
if len(candidates) == 1:
return Match(candidates[0], payout, level="amount")
# no unique hit -> exception list
return Unmatched(payout, reason="no_unique_match")Resolving and Posting Fees Correctly
A payout is rarely equal to the order amount. Payment providers deduct transaction fees, often a percentage discount plus a fixed amount per transaction, as well as possible exchange rate or payout fees. Anyone who only holds the net payout amount against the gross receivable creates a difference on every transaction -- and thus an apparently open residual amount that clogs up accounting.
The reconciliation engine must therefore master the gross-net split: the receivable is settled in full, the fee is posted separately to an expense account. This is not only a technical but also a tax requirement -- the input tax from provider fees needs to be captured correctly. A well-thought-out DATEV connection maps this logic in the account assignment.
| Item | Amount | Posting |
|---|---|---|
| Order receivable | 120.00 EUR | Debtor to Revenue |
| Provider payout | 118.20 EUR | Bank to Debtor |
| Provider fee | 1.80 EUR | Fee expense to Debtor |
| Residual debtor balance | 0.00 EUR | settled |
It is important that the fee logic remains configurable per provider. Each provider has its own model of percentage and fixed components. The engine should adopt the actually deducted fee from the payout report instead of calculating it -- this keeps the posting congruent with the real payout, even with differing conditions or special rates.
Chargebacks, Reversals and Exceptions
Chargebacks are the most unpleasant part of reconciliation. They often appear as negative items in a later payout, without a direct reference to the original order. The average chargeback rate in retail was 0.26 percent in the third quarter of 2025, 53 percent above the value at the start of the year (Chargeflow, 2025); for card-not-present transactions it is significantly higher at 0.6 to 1 percent (Chargeflow, 2025).
Add to this the problem of so-called friendly fraud: according to estimates, around 75 percent of chargeback cases go back to reversals by actually legitimate customers (Juniper Research, 2025). For reconciliation, this means: every reversal must be assigned to the original transaction, the associated receivable reopened and the fee for the chargeback captured separately.
Keep Thresholds in View
A forced match is more expensive than an open exception. Whatever cannot be assigned uniquely belongs transparently on the exception list -- not silently in the ledger.
All items that cannot be uniquely assigned belong in an exception list with a traceable reason: no hit, ambiguous hit, amount difference or unknown reference. This list is the working surface for the accounting team and at the same time the point where the matching rules are refined. A robust error handling ensures that no item is silently lost.
Posting to the ERP and to DATEV
The result of reconciliation is only valuable if it arrives cleanly in the target system. Here two paths diverge: in smaller setups, the reconciliation runs on the open items in financial accounting, for example directly in DATEV. In larger structures with a leading ERP such as SAP or Microsoft Dynamics, the ERP maintains the open items, and the reconciliation posts the incoming payments there.
In both cases, the posting should be idempotent: if the same payout report is accidentally imported twice, no double posting may arise. This is achieved via unique transaction IDs and an import status per record. Strategies for idempotency and retries are not a luxury here but a must -- especially when payout files are processed automatically.
Every posting should generate a complete document and audit trail: which payout, which transaction, which open item, which fee, which timestamp. This is relevant not only for a GoBD-compliant document chain but also for later troubleshooting. In the event of differences, it can be traced seamlessly which rule applied and which amount flowed where.
Daily Batch Reconciliation
The payout reports are imported and posted once a day. Simple, robust and sufficient for most merchants.
Event-Driven Reconciliation
Provider webhooks trigger the reconciliation as soon as a payout is available. Closer to real time, higher technical requirements.
Project Process of a Reconciliation Integration
A reconciliation solution is not built off the shelf but adapted to the specific payment and accounting landscape. The process typically follows five phases, with close coordination with accounting and tax advisor being decisive for success.
The Five Phases of a Reconciliation Integration
- 1
Inventory
Which payment providers, which payment methods, which ERP or DATEV product, which special cases such as partial payments or vouchers are in use.
- 2
Data Connection
Connection of the payout reports via API or file import, of the orders from the shop and of the open items from the target system.
- 3
Configure Rule Set
Definition of the matching stages, tolerance windows, fee accounts and chargeback handling in coordination with accounting.
- 4
Test Run with Real Data
Reconciliation of historical payouts, checking the auto-match rate, fine-tuning the rules and the exception list logic.
- 5
Go-Live and Monitoring
Productive operation with monitoring of the rate and the exceptions, continuous refinement of the rule set.
- Inventory: Which payment providers, which payment methods, which ERP or DATEV product, which special cases such as partial payments or vouchers are in use.
- Data connection: Connection of the payout reports via API or file import, of the orders from the shop and of the open items from the target system.
- Configure rule set: Definition of the matching stages, tolerance windows, fee accounts and chargeback handling in coordination with accounting.
- Test run with real data: Reconciliation of historical payouts, checking the auto-match rate, fine-tuning the rules and the exception list logic.
- Go-live and monitoring: Productive operation with monitoring of the rate and the exceptions, continuous refinement of the rule set.
The Lever Lies in the Auto-Match Rate
Common Pitfalls and How to Avoid Them
From project practice, the same pitfalls keep crystallizing out. Anyone who knows them can plan for them from the outset instead of retrofitting them expensively later.
- Fees ignored: Anyone who only holds net against gross creates differences on every transaction. The gross-net split belongs in the rule set from the start.
- Bulk payouts not resolved: A payout amount covers many orders. Without resolution into individual items, the reconciliation remains coarse and error-prone.
- References too short: Payment reference texts are truncated. Short, unique references in the payment reference noticeably increase the auto-match rate.
- Chargebacks without reference: Reversals must be assigned to the original transaction, otherwise negative items remain unexplained.
- No idempotency: Without unique transaction IDs, a duplicate import run leads to double postings and incorrect balances.
- Missing exception list: Forced assignments distort the figures. Real exceptions belong transparently in an exception list.