FD10N — Customer Balance Display by Period

FD10N displays a customer's accounts receivable balance broken into fiscal year and period columns, for a single company code selection. It is the customer-side counterpart of FS10N (GL) and FK10N (vendor), sharing the same underlying logic: period totals are pulled from summarized transaction figures on the customer master, not recalculated from every document at runtime. The structural fact that causes most confusion is that this summary excludes special GL transactions (down payments, guarantees, bills of exchange) unless the special GL indicator column is explicitly requested, so the total shown here can differ from what FBL5N returns for the same customer and period unless both views are compared with the same scope.

FD10N is reached for during period-end AR reconciliation, when a customer disputes a statement total, during credit review before releasing a blocked sales order, or when checking whether a balance carryforward ran correctly at year start. It sits between the aggregate view (a GL reconciliation account balance in FS10N) and the document-level view (FBL5N). Consultants use FD10N first for a quick trend across periods, then switch to FBL5N or drill down from a period cell when a specific document needs identifying. Fiori-based balance and line item apps cover the same ground on newer S/4HANA front ends but FD10N remains the fastest route in a GUI-heavy support call.

In SE16, pull KNC1 filtered on the customer number, company code, and fiscal year; sum the period debit and credit fields and compare against the FD10N screen total. To confirm the split behind that total, pull BSID and BSAD filtered on the same customer and company code, restricted to posting date within the period in question; the sum of both should equal the KNC1 period movement. A mismatch usually means special GL amounts sitting in KNC3 were excluded from one side of the comparison, or a document posted with a back-dated posting date that lands outside the period the reader expected.

FD10N still runs on S/4HANA and the entry screen is unchanged. Underneath, the summarized figures are sourced through compatibility views over the universal journal rather than a purely independent classic table update, so the display logic and its exclusions (special GL handling, period scoping) carry over unchanged even though the storage model changed. Fiori apps for customer balance and line item review exist as the newer alternative for users working entirely on the Fiori launchpad, but FD10N is not deprecated and remains the faster path for a consultant already in the GUI.

This is functional AR/FI territory; a competent FI consultant should resolve balance-reading questions without escalation. Basis involvement is limited to authorization objects blocking company code or customer access. ABAP involvement only arises if a custom report or interface writes directly to KNC1/KNC3 outside standard posting logic. A clean handover states the customer, company code, fiscal year and period in dispute, the exact comparison already run against FBL5N or FS10N, and whether special GL amounts were included in that comparison.

FS10N is the direct structural sibling for GL accounts and is worth comparing side by side to understand how the same period-total logic applies to a reconciliation account. FK10N is the vendor-side equivalent and useful when a customer and a vendor are the same business partner in an intercompany setup. FBRA is relevant whenever a reversal is suspected of distorting a period balance, since reversing a clearing changes the open/cleared split that FD10N's drill-down relies on. F-28 is worth reviewing when the dispute traces back to a payment that cleared against the wrong period or the wrong open item.