A group controller signs off the month-end close on the strength of a clean subledger. Invoices matched against payments, lines stamped as cleared, nothing left in the open item list that anyone needs to explain. Weeks later a supplier statement arrives from a subsidiary market and the balance does not agree.
Nothing malfunctioned. Clearing and reconciliation are two different operations, and an ERP performs only the first one by design. Clearing closes your ledger against itself. Reconciliation compares your ledger against somebody else's. The distinction sounds academic right up to the point where it costs a quarter's worth of aging accuracy, and it is worth being precise about, because English uses the same root word for both.
Clearing is a single-ledger operation
Open item management is the foundation of SAP's subledger architecture. When a customer invoice is posted, the line sits open. When the payment arrives, the invoice and payment lines are linked into a single clearing document, manually through F-32 or in bulk through automatic clearing (F.13), and both lines drop off the open item list. Those transaction codes are documented in SAP's open item clearing documentation.
Every input to that operation comes from your own books. The invoice is your posting, the payment is your posting, the matching criteria are your parameters. The counterparty's ledger appears nowhere in the equation. When clearing succeeds, the only thing you have learned is this: the receivable I recorded was closed by the payment I recorded.
Reconciliation asks a different question. Does the receivable I recorded match the payable the counterparty recorded? You cannot answer that from inside your own system, because half the answer is not there.
"Reconciliation account" is a naming trap
Every customer and vendor master record in SAP carries a reconciliation account field. It determines which general ledger control account the subledger posting flows into: the receivables or payables control account.
What it guarantees is integrity. The sum of subledger balances stays tied to the control account balance in the GL, because you cannot post directly to the control account. That is a genuinely valuable control. But the name misleads. Nobody is agreeing to anything here. Two internal layers of your own bookkeeping tie out to each other, and that is all.
The reconciliation account tells you your ledger is internally consistent. Reconciliation tells you it is consistent with the outside world. Anyone reading a control matrix should treat the first as an architecture decision and the second as an evidence-gathering exercise.
Where automatic clearing stops
Automatic clearing (F.13) looks for offsetting line items using defined criteria and closes them in bulk. It works best where the payment carries a clean invoice reference and the amount matches to the cent.
Cross-border and emerging-market flows break those conditions constantly. Remittance advice travels by email while the payment travels through the banking network, and the two never meet in the ERP. One wire settles five invoices. A customer short-pays and leaves the remainder for next week. A foreign-currency invoice leaves a rounding remainder because the booking rate and the bank rate differ. A credit note or an offset lands in the middle. None of these pass automatic clearing; they accumulate and fall to a human. We covered why linking a payment to an invoice is genuinely hard in our piece on FIFO and partial payment matching.
Here is the point that gets missed. Clearing those items manually is still not reconciliation. You have closed an open item in your own ledger. You may well have closed it against the wrong invoice, and the ledger will never tell you.
Clearing does not change the balance. It rearranges the lines inside the balance. That is precisely why a wrong clearing is silent.
What a silent error looks like
Consider a hypothetical, constructed to show the mechanism rather than drawn from a real case. A supplier issues two invoices in the same month, for identical amounts, covering different service lines. The following month a single wire goes out for exactly that amount, with no invoice reference in the narrative. Automatic clearing matches on amount and closes the earlier of the two invoices.
The total balance is correct: one invoice remains payable. But the supplier applied that same payment to the second invoice in their own books. Both sides show the same balance and completely different open item lists. A balance-only confirmation letter cannot see this. Both parties sign off as agreed.
The difference surfaces months later from an unrelated direction. The supplier charges late interest on the invoice still open on their side, your aging report shows it as closed, and you have nothing to dispute with. The close was fast. It was not correct.
How far intercompany reconciliation goes
SAP's intercompany matching and reconciliation capability exists to close part of exactly this gap. It compares the ledgers of two company codes, shows differences at line level, and lists what cannot be explained. That is a genuinely two-sided reconciliation.
The scope, though, is in the name. Suppliers, customers and dealers are outside it by construction. And even inside a group there is an exception, usually the painful one: an affiliate that consolidates but was never migrated, a joint venture, a recently acquired company still running its old package. On the org chart they look internal. In the system they are external. The intercompany report shows them clean because it cannot see them at all.
The same boundary separates two categories of software that get shelved together. One category sends balances out and collects confirmations; the other compares two ledgers line by line. We set that distinction out in sender versus matching engine.
What the numbers say
APQC benchmarks put top-quartile monthly close at 4.8 days or fewer, the median at 6.4 days, and the bottom quartile past 10 days. Ventana Research reported in 2023 that 31 percent of organizations have automated most or all of their reconciliations, while 58 percent close within six business days. Read together, the picture is clear: many close fast, few automate reconciliation. What accelerates the close is usually clearing, not agreement.
The cost accumulates somewhere measurable. APQC puts duplicate or erroneous payments at between 0.8 percent of annual disbursements at top quartile and 2 percent at bottom quartile. A duplicate payment is, by definition, a payment that passed cleanly through the clearing screen. It found an open item to close, so nothing objected.
On the detection side, ACFE's 2024 Occupational Fraud report ranks how frauds are first detected: tips 43 percent, internal audit 14 percent, management review 13 percent, document examination 6 percent, account reconciliation 5 percent, and by accident 5 percent. Median loss was 145,000 dollars and median duration 12 months. Read that list carefully before drawing a conclusion: reconciliation sits fifth, behind management review and document examination, so it is a weak detection channel on its own and no reconciliation tool should be sold as a fraud control. What the same report does associate with roughly halving both median loss and median duration is proactive data monitoring and analysis. The difference lies between closing items and comparing them. (These figures are from the 2024 edition; ACFE has since published a newer one.)
The Turkish leg: local ledgers, a one-month clock, audit evidence
For a group with a Turkish subsidiary or a Turkish supply base, this gap has a specific shape. Your counterparties there are not on your instance and mostly not on SAP at all. They run Logo, Netsis, Mikro, Luca, Zirve or a spreadsheet, and their period-end hygiene has its own vocabulary. Logo Netsis documentation, for example, defines a reverse-balance account check as its own report, used at period end to find receivable or payable accounts sitting on the wrong side so the balances can be moved to advance accounts. It is a sound control and it is still single-ledger: it tells you something looks odd inside your own books, not that the account agrees with anyone.
The legal clock is worth knowing before you delegate confirmations to a local finance team. Article 94 of the Turkish Commercial Code provides that a party receiving a statement of the current account balance is deemed to have accepted it if no proper objection is raised within one month. The nuance that matters in practice: this consequence operates in the context of a written current account agreement, since Article 89 makes written form a validity condition. Without a written agreement, silence in response to a confirmation letter may not by itself constitute acceptance, so a group treasury that assumes a one-month deadline protects it everywhere is assuming too much.
Audit evidence follows the same logic. Under Turkish Auditing Standard BDS 505, the local adoption of the IAASB standard on external confirmations, an external confirmation is audit evidence the auditor obtains as a direct written response from a third party, in physical, electronic or another medium. A clearing report is not that. Lines showing as cleared inside your own system are your assertion about your own books, not a response from anyone else.
What is needed where clearing ends
This gap is not an ERP defect. It is a question of scope. SAP was built to manage your ledger and it does that job well. Reaching the second ledger is a different operation: obtain the counterparty's statement, compare the two lists item by item, and show which item produced the difference.
That is where iFinances sits. It brings ledger records, bank statements and e-invoice data into one table, working independently of the source system, whether that is SAP, Logo, Mikro, Netsis, Luca, Zirve or a plain Excel export. The matching engine handles FIFO and invoice-specific clearing, splits partial payments, distributes lump-sum payments, applies cent-level tolerance, and converts across currencies using the official central bank rate. It compares the name in a bank narrative against your company records with Turkish-character-folding similarity, but it presents that as a suggestion; the decision stays with a person. Every match carries a written reason next to it: the amount agrees, the date fits, the reference points to this invoice. The counterparty can upload their own statement through a secure link without needing any software. How the three sources cross-check each other is covered in our piece on three-way reconciliation, and the process itself is laid out on the supplier statement reconciliation page.
The honest boundary matters too. iFinances does not keep books, does not create postings, and does not close any line on its own. It is not a replacement for clearing in SAP. It brings in the second ledger that clearing was never designed to see. Clearing is about the speed of your close. Reconciliation is about its accuracy. You need both, and doing one does not count as doing the other.
Frequently Asked Questions
What is the difference between clearing and reconciliation?
Clearing is an internal operation. It links offsetting open items inside one ledger and marks them closed, and every input to it is your own posting. Reconciliation is an external one: it sets your ledger beside the counterparty's and identifies which item created the gap. A ledger can be fully cleared and still disagree with every party you trade with.
Does SAP's reconciliation account reconcile anything with a counterparty?
No, and the name is the reason people assume otherwise. The reconciliation account on customer and vendor master data routes subledger postings into a general ledger control account, so the subledger total and the control account balance stay tied to each other. That is an internal integrity control between two of your own layers. No third party is involved at any point.
Why does automatic clearing leave so many items open?
Because it needs a clean signal. It looks for offsetting lines using defined criteria such as reference, amount and currency, and real payment behaviour breaks those criteria constantly: one wire settling several invoices, short payments, remittance information that never reaches the bank narrative, rounding left by a booking rate that differs from the bank rate, credit notes and offsets. What does not match falls to a person, who closes it by judgement rather than by evidence.
Do intercompany reconciliation tools cover suppliers and customers?
No. The scope is in the name: transactions between entities of the same group, sitting in the same system. Third-party suppliers, customers and dealers are outside it by construction. So is a consolidated affiliate or a recent acquisition still running its own ERP, which is why an intercompany report can look clean while a material part of the group's external exposure has never been compared to anything.
How do you reconcile with a Turkish subsidiary or supplier that does not run SAP?
You reconcile against their export, not against their system. Turkish entities typically run Logo, Netsis, Mikro, Luca, Zirve or a plain spreadsheet, and none of these will connect to your instance. The practical route is to collect their statement in whatever format it comes, normalise it, and compare it line by line against your own open items, keeping the two ledgers separate rather than trying to merge them.
✦ iFinances — See what you're missing.
