Open item

For a finance function running several Turkish entities, the open-item list is the one view of a trade account that survives translation. Any system can produce a balance; only an open-item list says which documents make that balance up. An issued invoice enters the account as an open item and leaves it when a receipt, a credit note, an offset or an advance application is booked against it, and until then it carries both the balance and its own line in the aging report. Where the list lives depends on the system: SAP publishes customer line items through FBL5N and vendor line items through FBL1N, while Turkish local packages usually deliver the same content as a current-account statement, the report local teams call a cari hesap ekstresi, or as an open-invoice report that exports to Excel. The label changes from system to system; the working surface does not.

Two readings of the term cause most of the trouble. Open is not the same as overdue: an invoice raised yesterday and not due for another sixty days is entirely open, and it is the aging report, not the open-item list, that separates the two ideas. Clearing is not the same as reconciliation either. Clearing is a one-sided bookkeeping action that reduces your own balance, and it says nothing about whether the counterparty holds the same documents, in the same amounts, on the same dates. An account cleared to zero can still hold payments applied against the wrong invoices, which is why a flat balance is weak evidence in an audit file and a poor answer to a customer disputing one specific document.

Mechanically, the interesting part is how cash is applied. One receipt can partly clear several invoices and one invoice can be touched by several receipts, and the application order is either invoice-specific, when a remittance advice or the payment description names the document, or first-in-first-out when nothing names it. That choice is not cosmetic: applying cash to the oldest invoice consumes the oldest aging bucket and flatters the aging report, while invoice-specific application leaves the old document open and keeps the real delay visible. Either way the leftover stays on the list as a residual item, and residuals of a few cents left uncleared quietly inflate the list over the years until its length measures old housekeeping rather than current risk. iFinances builds these applications across ledger records, the bank statement and e-invoice data together, splits partial payments, distributes lump-sum settlements and writes a reason beside every match. Data reaches it either through your system's Excel or CSV export or through the direct connection your system offers; both routes are ready, and which one you use is chosen together during setup.