Cash application

Cash application answers a question that recording the receipt does not: which invoices does this money clear, and for how much. It sits at the intersection of three sources, the line on the bank statement, whatever remittance advice the payer sent, and the open item list in the ledger. Two things make the Turkish case harder than the textbook one. Remittance advice is not a settled habit here, so the transfer description is frequently empty, truncated by the bank, or carries only a shortened trade name. And long Turkish company names are written differently by different banks, with legal form suffixes and local characters handled inconsistently, so the payer string on the statement rarely matches the master data exactly. An engine can generate candidates out of that; the person responsible for collections still decides which candidate is right, and the written reason next to the match is what survives into the audit file.

What makes application hard is not the amount but the split. When a customer pays ten invoices with one transfer, the cash arrives as a single line while ten items have to clear, and more than one split reconciles to the same total. Partial payments leave residuals. Credit notes are netted off. Foreign currency invoices produce an exchange difference between the invoice date rate and the payment date rate. Rounding and sub unit residuals move a figure by fractions of a lira, and that is the reason matching engines carry a small tolerance at all; early settlement discounts and bank charges are a different matter, because they are known and often material differences that belong in the match as identified items rather than being absorbed by a tolerance. Turkey adds one case that surprises newcomers: on certain supplies the buyer withholds part of the VAT and pays it straight to the tax office, so the amount reaching your account is deliberately lower than the invoice total and the shortfall is not a dispute.

The most common mistake is treating a recorded receipt as an applied one. When the bank reconciliation agrees, total cash is right, but which customer and which invoice that cash belongs to is a separate question, and the total can agree while the breakdown is wrong. The second mistake is reading first in first out application as evidence. It is a reasonable default that clears the oldest invoice first, but if the payer intended a different document, both sides land on the same balance through different lines. The third is parking unapplied cash in a suspense account and leaving it there, which quietly corrupts the aging report and every collection call built on it. The fourth is leaving the decision in one person's memory, so that six months later nobody can say why that payment went to that invoice.

A practical note for a regional finance function: unapplied cash tends to be reviewed upstream as a single number, while the work that moves it is local, manual and invisible from a consolidation screen. If you want that number to fall, ask the local team for three things rather than a balance. The age profile of the unapplied pool, not its size. The share of incoming receipts that carry a usable invoice reference. And the list of payers who never send one. All three are answerable from the bank statement and the open item list without any new reporting, and together they say whether you have a matching problem or a remittance problem, which need different fixes.

Under continuous reconciliation application is not saved for period end; it runs as data arrives, and everything unmatched accumulates on an exception list that stays short enough to close while people still remember the underlying event.