Clearing

In practice, clearing usually means deciding which invoices a receipt or a payment settles. In SAP, customer and vendor line items are listed through FBL5N and FBL1N; the F.13 automatic clearing program (SAPF124) closes items that satisfy the configured criteria, while F-32 clears customer items by hand. Turkish accounting and ERP packages generally call the same operation kapatma, or closing. The effect is identical everywhere: cleared items drop out of the open item list, leaving only lines that are genuinely outstanding. The order of application is a decision in its own right, since first in, first out starts from the oldest invoice, while invoice-specific application states directly which document a payment belongs to.

Its role in reconciliation is preparatory. A well cleared ledger produces a short open item list that can be compared with a counterparty line by line. An uncleared ledger shows the invoice as open and the payment as a separate floating line, so when the two lists are set side by side the number of apparent differences runs far above the real one and the comparison loses its meaning. Partial settlements matter here too: whether the remainder is left as a residual item or the invoice is partially closed changes the shape of the open item list, and the aging report, for every period that follows.

The common mistake is treating clearing as reconciliation. Clearing works only on data you entered yourself, so when the system pairs two of your own records what it demonstrates is internal consistency, not external truth. An invoice that was never issued, a receipt that was never booked, or a payment posted to the wrong account stays invisible in a perfectly cleared ledger. Reconciliation exists to close that gap by bringing in the bank statement and the counterparty's own records. iFinances keeps the distinction: it proposes matches and puts a written reason beside each one, but closes no line by itself, because the decision belongs to a person.