The money arrived. The invoice number didn't.
Every bank receipt is linked to its open invoice with a written reason, and your team approves.
Allocation to two invoices proposed
₺175,000.00 split by FIFO into 145,000.00 + 30,000.00.
Which invoice each payment matched is visible line by line; you post the clearing in your own system.
Illustrative screen · sample data
Payment matching links every receipt on the bank statement to the right invoice in the ledger. For a group with a Turkish subsidiary, the gain is knowing which invoice was actually paid. For example, a TRY 48,250.00 transfer on June 18, 2026 is linked to invoice FT-2026-0412. The reason is written next to it. iFinances does not keep books, does not create entries and never clears a line on its own.
iFinances puts the invoice list, the payment list, the bank statement and e-invoice (e-Fatura) data in one table. The engine splits partial payments, allocates lump sums across invoices and flags cent-level differences within a fixed tolerance. It links a foreign-currency invoice to a lira payment at the TCMB (Central Bank of Türkiye) official rate. Every proposal carries a written reason a reviewer outside Türkiye can read, and your team decides.
Why is payment matching hard?
The problem shows up in six separate places. Each one is small on its own, and together they stretch the month-end close. Amounts are illustrative.
Unapplied cash inflates the ageing
The subsidiary's receivables ageing shows a large over-90-day bucket. Part of it is cash already received but never applied to an invoice. Lump sums that equal no single invoice, half-linked partial payments and transfers from unnamed senders sit inside it. The provision discussion then starts from a number nobody trusts.
Three rates for one payment
An invoice is issued for EUR 10,000.00 and the customer pays in lira. The group consolidates at its own rate. The ledger holds the invoice-date rate, and the bank credited lira at the payment-date rate. The three numbers differ, and the gap is worked out by hand. It usually waits until month end.
FIFO clears the oldest invoice
A customer has three open invoices, January 40,000.00, February 25,000.00, March 25,000.00. The customer pays March and 25,000.00 arrives. FIFO clearing (first in, first out) applies the cash to January. The balance is right, the ageing is wrong, and a reminder goes out for March.
A partial payment is left half-linked
Invoice FT-2026-0412 is TRY 48,250.00, and TRY 30,000.00 arrives on June 18, 2026. In the ledger the invoice shows either open or partially paid. Nothing records which payment will settle the remaining TRY 18,250.00. When another TRY 18,250.00 arrives two weeks later, the link chosen at clearing time cannot be traced.
One transfer, twelve invoices
A single transfer of TRY 312,450.00 lands with the description 'August invoices'. The counterparty has twelve open invoices. Which of them add up to that total? Trial and error by hand takes hours, and the payment usually waits unapplied.
The sender name does not match
A bank line reads only 'TRANSFER', and the sender appears as 'AKDENIZ METAL SAN VE TIC LTD STI'. The ledger holds the same company as 'Akdeniz Metal Sanayi ve Ticaret Ltd. Sti.' with full punctuation. Exact text matching fails. The payment waits as an unidentified sender and the account stays open.
How does it work?
Five steps. At each step, here is what your team does and what iFinances does.
- 1
Upload the files
Your local team exports the invoice list, the payment list and the account statement from the ERP. Excel or CSV is enough. It downloads the statement from the bank and uploads everything to iFinances. iFinances identifies the format from content and detects columns and the debit/credit sign convention. Anything it does not recognize is asked, not guessed.
payments_2026-06.xlsx · invoices.xlsx - 2
The rules run
Your team waits, and the wait is measured in minutes. iFinances applies FIFO or invoice-specific application, partial-payment splitting, lump-sum allocation and a fixed cent-level tolerance. It links foreign-currency invoices to lira payments at the TCMB official rate. Where two invoices are plausible for one payment, both appear with their reasons.
FIFO · partial · bulk · cent tolerance - 3
The reason is written
iFinances links exact matches first, on amount, date, reference and invoice number. For example, the TRY 48,250.00 transfer of June 18, 2026 is linked to invoice FT-2026-0412. Next to it reads 'amount and date exact, description contains the invoice number'. Your team reads every reason on screen, in English or Turkish.
175,000.00 → INV-0401 + INV-0402 ✓ - 4
Your team reviews the exceptions
iFinances collects unapplied payments, unmatched invoices and suspicious records in one list. Duplicate invoices, off-pattern amounts and unexplained differences land here. Your team approves or rejects each proposal. No match becomes final without approval.
KARADENIZ 30,000.00 · partial · 22,000.00 open - 5
Carry the result to the ERP
Your team exports the approved list to Excel and posts the clearing in its own ERP. iFinances generates a reconciliation letter from the same data. The letter carries a summary table per currency and a serial number, and the signed copy is archived. The counterparty uploads its own statement through a secure link, with no account needed.
Approved list → Excel → you post clearing
Automatic clearing versus payment matching
Both look at the same payment. The difference is what each one sees and whether a reason is written down.
- FIFO applies cash to the oldest invoice.
- A partial payment's remainder has no traceable source.
- A lump sum waits unapplied; invoices stay open.
- A cent difference stays open or needs an adjustment.
- The FX difference is worked out by hand.
- Bank statement and e-invoice sit outside the clearing screen.
- The invoice actually paid is proposed with a reason.
- The payment is split; the remainder shows under it.
- The invoice set that sums to it is proposed.
- Flagged within tolerance and kept as a visible line.
- Matched at the TCMB rate; FX difference separate.
- Ledger, bank statement and e-invoice in one table.
What we see in the field
One external statistic, two anonymized customer observations.
According to APQC, duplicate and erroneous payments amount to 0.8% to 2% of annual payments. Most of those errors hide inside unapplied cash. Typical cases are an invoice paid twice or a transfer cleared against the wrong account. Matching makes those lines visible.
At a mining-sector customer, most payments showing as open were partial payments and lump-sum transfers. Because only exact amounts had been searched for, none of them matched. Once partial splitting and lump-sum allocation ran, the exception list shrank. Every remaining line carried a reason, and the supplier reconciliation was done line by line.
At a manufacturing-sector customer, foreign-currency invoices had been paid in lira and the accounts showed the wrong sign. Cross-currency matching at the TCMB rate linked the payments to their invoices. FX differences went to their own lines, and the accounting decision stayed with the team. Most unidentified transfers were proposed to the right counterparty through name similarity.
Try it on one period of your subsidiary's payments
Bring one period of invoice list, payments and bank statement from the Turkish entity. See which payment belongs to which invoice, with the reason next to each. Thirty minutes, no slides.
Frequently asked questions
Clearing runs inside the ledger and sees only the ledger. Matching brings the bank statement and e-invoice data into the same table. It splits partial payments, allocates lump sums and writes a reason next to every match. iFinances does not replace the ERP. It answers 'which invoice does this payment belong to' before anything is posted.
No. iFinances does not keep books, does not create entries and never clears a line on its own. It exports the approved match list to Excel. Your local team posts the clearing in the ERP under its own authorization. The ledger keeps a single owner.
For a partial payment the invoice is split. A TRY 30,000.00 receipt against invoice FT-2026-0412 (TRY 48,250.00) is linked beneath it. The remaining TRY 18,250.00 shows as open, and the next payment is proposed against it first. For a lump sum the engine finds the invoice set that sums to the transfer. Both proposals wait for approval.
A foreign-currency invoice and a lira payment are matched at the TCMB official rate. The FX difference is shown on its own line, and how it is booked stays your decision. For cent-level differences the engine applies a fixed tolerance. A difference within tolerance is flagged as matched and kept visible. Anything outside tolerance goes to the exception list.
No. The invoice list, payments and account statement from the ERP, plus the bank statement, are enough. All come as Excel or CSV. The reader recognizes the format from content and detects columns and the sign convention. Nobody at group level needs a login to the subsidiary's ERP. A direct connection is ready for all fourteen systems.
30 minutes. With your own data.
Live demo. No commitment.
- Live demo — the system, not slides
- No prep, instant walkthrough
- A tailored quote in your inbox