SAP Accounts receivable

AR records customer invoices (often from SD billing), applies incoming payments, manages overdue receivables through dunning, and keeps the customer sub-ledger reconciled to the G/L. It ensures the organisation collects what it is owed and that receivables are accurate.

• Customer invoices: from SD billing or direct FI.
• Incoming payments & clearing: matching receipts to invoices.
• Dunning: reminders for overdue amounts.
• Credit management links to reduce risk.

Customer invoices usually arrive from billing rather than being typed, but FB70 posts one directly in FI when there is no sales document behind it. Incoming payments are F-28, and F-32 clears an account without posting new money, which is what you use when a credit and an invoice need to cancel each other.

FBL5N is the transaction AR people live in: customer line items, open or cleared, for any date. Dunning runs through F150. The customer master is maintained through BP in S/4HANA, and its company code view holds the payment terms, the reconciliation account and the dunning procedure.

The tables are BSID for open customer items and BSAD for cleared ones, sitting behind the general BKPF and BSEG pair. In S/4HANA those are views over ACDOCA rather than separate stored tables.

Twenty minutes, and it covers the part of AR that interviews actually probe.

1. Post a customer invoice with FB70. Note the reconciliation account on the customer line: you did not choose it, the customer master did.
2. Open FBL5N for that customer and select open items. Your invoice is there.
3. Post an incoming payment with F-28 for the full amount and select the invoice to clear.
4. Run FBL5N again with cleared items selected. The invoice now shows a clearing document number, and the open item has gone.
5. Now do it again but pay less than the invoice. The item stays open with a residual, or a partial payment is recorded, depending on which you choose, and the difference between those two options is worth understanding before month end rather than during it.

AR is the finance end of order-to-cash: SD billing posts the receivable, AR then collects it, and receipts post to bank accounting. It reconciles to the G/L and links to credit management to control customer risk. Clean customer master (BP) is essential.

The reconciliation account is the mechanism holding AR and the general ledger together. Every customer posting hits the customer sub-ledger and its reconciliation account at once, which is why you cannot post directly to that account: it would break the agreement between the two. See SAP FI AP for the mirror image on the supplier side and the chart of accounts for where those accounts are defined.

• How cash is applied. Manual matching is accurate and slow. Automatic clearing from a bank statement is fast and depends entirely on customers quoting a reference. Most businesses need both and should decide the tolerance for automatic matching deliberately.
• Residual or partial payment. A residual closes the original and creates a new item for the balance, so the ageing restarts. A partial leaves the original open with its original date. Collections teams usually want partial; the reporting consequence is why.
• Dunning levels and tone. How many reminders, at what interval, and whether the last one blocks the customer for new orders.
• Where credit management sits. A credit block stops a sales order, so the rules belong to finance and the consequences land on sales.

AR is judged on one number, how much is owed and how old it is, and most of the module exists to move that number.

Payment terms set the expectation. They are copied onto the invoice at posting from the customer master, which is why changing the master does not move existing items. Terms carry a baseline date and can include a cash discount, and getting the baseline wrong shifts every due date in the ledger.

Dunning automates the chasing. A dunning procedure defines levels, the interval between them and what each level does, from a polite reminder to a hard block. The run proposes, a person reviews, and only then does anything reach a customer, which is deliberate: an automated letter to a customer in a dispute is expensive.

Credit management decides whether new business is allowed. A limit per customer, checked when a sales order is created, and a block if it is exceeded. That block stops a shipment, so the rule belongs to finance and the pain lands on sales, and any design that ignores that tension fails in week one.

Ageing is the report the whole thing is measured by, grouping open items into buckets by days overdue. It is only useful if somebody works the oldest bucket, which is a process question rather than a system one.

At month end the sequence is: post everything, apply cash, review disputed items, run dunning, then reconcile the sub-ledger to its reconciliation account before the period closes. See SAP FI integration for how those postings arrive.

Not every customer item is an ordinary receivable, and special general ledger indicators are how SAP keeps the unusual ones separate.

A down payment received before delivery is money you hold and have not earned. It belongs on the balance sheet somewhere other than trade receivables, and a special indicator on the posting sends it to its own reconciliation account while still showing on the customer's account.

Guarantees and security deposits work the same way. So do doubtful receivables, where an item is reclassified because collection is in question, without deleting the original invoice.

The mechanism is one field. The posting hits the customer, and the indicator decides which general ledger account carries it. That is why a customer balance and the trade receivables account can legitimately differ, and why an ageing report that ignores special items can mislead.

When a down payment is later cleared against the real invoice, the special item is reversed and the ordinary receivable reduced. Getting that sequence right at year end is a routine audit question.

• Unapplied/mis-applied cash, receipts not cleared to invoices.
• No dunning, overdue receivables ignored.
• Ignoring credit management, over-exposure to risky customers.

• Posting a credit memo instead of clearing. If the money arrived, clear the item. A credit memo says the invoice was wrong, which is a different statement.
• Ageing that nobody reads. The report is only worth running if somebody acts on the oldest column.
• Changing payment terms on the master and expecting old invoices to move. Terms are copied onto the document at posting, so existing items keep what they were given. See SAP FI reports for finding them.

• Clearing with a tolerance nobody agreed. Small differences written off automatically are convenient, and the limit should be a finance decision rather than whatever the system shipped with.

Clearing an invoice is straightforward, and configuring the payment terms, dunning and automatic clearing that make a real ledger behave is the part you do in the course.

The habit worth taking from this page: when a customer balance looks wrong, check for special general ledger items before anything else. They sit on the account, they are excluded from trade receivables, and they explain a difference that otherwise looks like a reconciliation fault.