Unidentified transfer

An unidentified transfer is cash in the bank that cannot be tied to a customer or an invoice, and in Turkey it is closer to a structural condition than an occasional accident. Remittance advice is not an established habit, so the description field is often empty or filled with one generic word. Bank statements truncate the sender name at a fixed character limit, and Turkish trade names are long, carry legal form suffixes and use characters that different banks transliterate differently, so the same payer can appear as a different string in every statement you open. Inside a group, the transfer frequently leaves the account of a sister company while the invoice was issued by another legal entity. Where a factoring house, collection agent or financing arm is involved, the name on the statement is not the customer's name at all. Add several similar amounts arriving from different customers on the same day and the statement on its own cannot say who paid what.

The cost is not the cash, which is safely in the account; it is the receivable that stays open behind it. That phantom debt ages, distorts the aging report and any provision built from it, and sends the collections team after a customer who has already paid. On the other side of the ledger the unapplied cash pool grows, and at period end somebody has to explain a suspense balance that belongs to nobody. The workable approach is to score candidate accounts on several weak signals at once rather than one strong one: the amount, the value date against the open due dates, the currency, a fuzzy comparison of the truncated sender string against registered trade names that folds local characters to their plain equivalents, and the shape of what is open on each candidate. Every candidate is a suggestion, a person decides, and the reason is written next to the decision. Where doubt remains, one line of confirmation from the payer resolves it faster than any rule.

The most common misreading is assuming that a clean bank reconciliation solves this. Bank reconciliation proves total cash is right; which customer that cash belongs to is a separate question, and the total can be correct while every allocation under it is wrong. The second is moving unidentified receipts into a suspense account and leaving them there, which hides the issue rather than closing it. The third is trusting an exact amount match on its own, since the same figure can be open on two different customers and a match made on the number alone corrupts two accounts instead of one. The fourth is expecting the paying entity to be the invoiced entity. Inside a group the two diverge routinely, and such a payment cannot be applied on the sender name or a single identifier alone: the group relationship has to be recorded on the account, the entity the payment was made for has to be confirmed, and the reasoning has to be written down.

There is a preventive side worth more than any matching rule, and it is mostly a treasury and commercial conversation rather than an accounting one. The payers who send nothing usable tend to be the same ones every month, which makes the problem finite rather than endless. Capture the format each of them actually uses, agree an invoice reference field with the largest of them, and make sure group payments state the entity they are made for. In a subsidiary where most cash comes from a short list of large customers, that work removes the bulk of the population before any engine has to guess at it.