Down Payment Not Offsetting Against the Final Invoice

Accounts receivable or accounts payable reports that a customer or vendor account still shows the full invoice amount as due even though a deposit or advance was clearly paid weeks earlier. The customer statement or vendor line item report lists both the down payment and the invoice as open, sometimes for the full gross amount each, so the account looks like it owes double what it actually does. Collections calls the customer, the customer pushes back saying the advance was already paid, and finance cannot explain in five minutes why the system still shows an outstanding balance. In the vendor case, the payment run tries to pay the full invoice again on top of the advance already disbursed, and someone has to manually block the payment before it goes out.

Pull FBL5N or FBL1N for the account with the special G/L indicator field included, filtered to show both open items: the down payment (indicator A) and the invoice (no indicator or a different one). Sum the two amounts against the actual commercial deal value; if they do not net to the expected balance, and no F-39 or F-54 document number appears linking them, the transfer never happened. Cross-check the assignment field on both lines to confirm they were even eligible to be matched automatically.

If the account only ever received a down payment request (noted item) and no actual payment, this is a process gap, not a system fault: the actual down payment must be posted first (F-29 customer, F-48 vendor) before any clearing is possible. If the actual down payment exists and simply was never transferred, run F-39 or F-54 referencing the invoice; this is a data fix, no transport needed. If the transfer fails on account determination, the missing special G/L clearing account assignment in OBXR or OBYR is a configuration fix requiring a transport through the normal change path, and should be corrected before more transfers are attempted rather than worked around per document. If the block is a reference or assignment mismatch, correct the assignment field on one of the two documents (where still permitted) or process the transfer manually specifying both documents explicitly rather than relying on automatic proposal. Tax mismatches usually require a manual partial clearing with the residual routed to a correction posting, agreed with tax and the account owner first.

The common reflex is to force the accounts through ordinary open item clearing (F-32 or F-44), selecting the down payment and the invoice together and letting the system zero the difference. This either rejects outright because special G/L items are excluded from standard clearing, or, if the poster overrides the selection and forces a manual clearing document, it removes the item from the open item list without running the proper transfer logic, meaning the down payment special G/L balance and the tax adjustment that should have happened never get posted correctly. The account looks clean but the reconciliation account and the tax ledger are now wrong underneath it.

Accounts receivable or accounts payable operations owns execution of the clearing transaction; FI configuration owns the special G/L account determination if that is broken. The handover note should list the customer or vendor number, the down payment document number and special G/L indicator, the invoice document number, the assignment and reference field values from both, and the tax codes used on each side.