No one tells you when you pay the same invoice twice.
Put the ledger, the bank statement and the e-invoice list side by side. The line that does not agree shows itself.
One proposed, one stays listed
Y-1182 agrees with the bank; Y-1187 stays on the list, you decide.
1 review · 847 agreeing lines. You only look at what is flagged.
Illustrative screen · sample data
This page explains anomaly detection with reconciliation data. It is for CFOs, controllers and internal auditors of a Turkish entity. They need to find missing invoices, duplicate payments and unexplained differences. The gain is simple. The ledger, the bank statement and the e-invoice (e-Fatura) list land in one table. Every line that does not agree is listed with a written reason.
iFinances keeps no books, creates no entries and never closes a line by itself. It flags the line where the three records disagree and writes the reason. The decision stays with your team. Say invoice FT-2026-0412 for TRY 48,250.00 shows two bank transfers dated June 18, 2026. iFinances flags the second transfer as a possible duplicate payment and explains why.
What does a single system miss?
Inside one system, error and fraud look consistent. The line that does not agree appears only when two records sit side by side.
Missing invoice
TRY 48,250.00 left the bank account on June 18, 2026. No matching invoice exists in the ledger or the e-invoice list. The ledger balances on its own, so the gap is not noticed by itself. Once the bank statement sits next to it, the line stays open.
Duplicate payment
Invoice FT-2026-0412 was booked twice, once as 'FT-2026-0412' and once as 'FT 2026 0412', and paid twice. The TRY 48,250.00 difference disappears in the totals, while two transfers sit plainly in the bank lines. iFinances flags a same-amount, same-counterparty pair with close dates as a possible duplicate payment.
Off-pattern amount
A supplier is paid between TRY 40,000.00 and TRY 50,000.00 every month. One month TRY 480,250.00 goes out. On its own this proves nothing, it is a place to look. The reason next to the flag explains the gap.
Unexplained difference
TRY 1,250.00 remains between the counterparty statement and account 320 (trade payables). Exchange differences, discounts or withholding tax, the tax deducted from a payment, do not explain it. A classic close rounds the difference away at period end. iFinances keeps it open and asks for a decision.
Unidentified bank transfer
A TRY 48,250.00 transfer arrives with an empty description and fits no counterparty on file. iFinances may propose a counterparty through name similarity. That similarity treats 'YILDIZ METAL' and 'Yildiz Metal San.' as the same name. If no proposal is possible, the line stays open and a person is asked, never a guess.
Control override
Approval workflows depend on people, and people can be persuaded or rushed. A control that reads three independent records against each other makes a transaction visible wherever those records disagree. Its limit is just as plain. A collusive purchase with a genuine e-invoice, payment and ledger entry will not be caught.
How does it work?
Setup is not an IT project. File upload and direct connection are both ready, and the path is chosen together at setup.
- 1
Upload three records
You upload the counterparty statement, invoice list and payment list from the ledger or ERP. You add the statement from the bank and the e-invoice list from the integrator. iFinances identifies the file format by content, not by extension. It reads xlsx, legacy xls, CSV and the HTML tables some banks save under an xls name. Any unrecognized column is asked about.
Ledger · bank · e-invoice · June - 2
The engine matches
You wait, this step is automatic. iFinances matches by invoice-specific clearing or FIFO, which clears the oldest invoice first. It splits partial payments and allocates one TRY 100,000.00 bulk payment across several invoices. Rounding tolerance is fixed, and cross-currency lines use the TCMB (Central Bank of Türkiye) rate. Every match gets a written reason.
Y-1182 ↔ Transfer 18.06 · 36,900.00 ✓ - 3
Exceptions are listed by type
You open the exception list. iFinances lists every unmatched line and writes its type wherever the data allows. The types are missing invoice, duplicate payment, off-pattern amount and unexplained difference. The label is not a verdict, it is a triage order that says where to look first.
Y-1187 · same amount · 2 days later - 4
You review and record the decision
You open the flag, read the reason, check the source record and write your decision. The options are error, timing, accepted difference or a signal handed to internal audit. iFinances stores the decision next to the line. The same line will not raise the same alarm next period. A line without a decision does not close.
Decision: 20.06 entry · timing · note - 5
Evidence accumulates
You do not wait for period end, you upload as data arrives. iFinances reruns the matching and keeps decisions and reasons attached to the line. The reconciliation letter, a per-currency summary table, is issued with a serial number. The signed copy goes into the archive.
847 agreeing · 1 review · archive
Balance check or line check?
Two habits share one name. The first looks at totals at period end and closes the file when the balance agrees. The second reads lines as data arrives and leaves the disagreeing line open. Most companies need both.
- If the total agrees, the period closes
- Trusts one record, the ledger balances internally
- Sampling, a handful of documents reviewed by hand
- Unexplained differences are rounded away
- Rests on a person's approval, can be overridden
- Evidence, an approved balance figure
- Even if the total agrees, unmatched lines stay open
- Reads ledger, bank and e-invoice against each other
- Every line is matched, exceptions are ranked
- Unexplained differences are labeled and need a decision
- Rests on data, not on personal approval
- Evidence, flag, reason, written decision, signed letter
What do you gain?
Three concrete gains. The case notes are anonymized and contain no customer amounts.
Duplicate payments surface within the period. Pairs of payments to the same counterparty under consecutive references land on the exception list. An example is two TRY 48,250.00 transfers dated June 18, 2026 for FT-2026-0412. At a mining-sector customer, some pairs were genuine duplicates and others were two separate same-day payments. The team reading the reasons drew the line, and each decision was written next to its row.
Unidentified transfers find their owner. At a manufacturing-sector customer, most bank transfers with no usable description got a name-similarity proposal. The team approved the proposal and the line was linked to the right counterparty. Lines with no proposal went to internal audit as unexplained differences. No line was closed by guesswork.
The auditor gets a line-level trail. Each flag keeps its type, its reason, who decided and when, attached to the line. The reconciliation letter is a per-currency summary table with a serial number. The signed copy is archived. The auditor sees the line list linked to the letter on the platform, not a screenshot.
Try it on your own data
Bring one period of counterparty statement, bank statement and e-invoice list. We match the three records in one table and list the disagreeing lines by type. Thirty minutes, no slides.
Frequently asked questions
No. iFinances is a reconciliation platform. It lists the lines that disagree across ledger, bank and e-invoice data. It writes the type and the reason. Whether a flag is an error, a timing difference or a signal to investigate is your team's decision. Concluding that fraud occurred is the job of internal audit and management.
We do not claim that figure. ACFE is the Association of Certified Fraud Examiners. Its 2024 report counts account reconciliation as the initial detection method in 5% of cases. We do not say reconciliation solves fraud. We say something narrower. The line where the records disagree becomes visible, and a person looks at it.
No. iFinances does not touch your bank or your payment system and blocks no transaction. As data arrives, it flags payment pairs that look duplicated. An example is TRY 48,250.00 sent twice to the same supplier on the same day. The recovery request or the correcting entry stays in your own process.
No system change. The counterparty statement, invoice list and payment list from your existing ledger or ERP are enough. Add the statement from the bank and the e-invoice list from the integrator. File upload and direct connection are both ready, and the path is chosen together at setup.
Each flag keeps its type, reason, decision and date next to the line. Flags not yet closed stay open on the exception list. The reconciliation letter is issued as a PDF. It is a per-currency summary table with a serial number, and the signed copy is archived. The line list is linked to the letter on the platform.
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