Accounts Receivable (AR)

AR is the customer side: what you’re owed, by whom, when, and how you get it in.

The process 

Sales Order ──▶ Delivery ──▶ Billing ──▶ AR Open Item ──▶ Cash Receipt ──▶ Clearing
                    │            │                              │
              COGS Dr        AR    Dr                       Bank Dr
              Stock Cr       Revenue Cr                     AR   Cr
                             Tax     Cr

Invoice posting 

Customer invoice, 10,000 goods + 1,500 VAT:
  Accounts receivable (customer ACME)  Dr 11,500
    Revenue                               Cr 10,000
    Output VAT payable                    Cr  1,500

And the cost side (posted at goods issue, not billing):
  Cost of goods sold                   Dr  6,200
    Inventory                             Cr  6,200

Note revenue and COGS post at different moments (billing vs goods issue). Matching them in the same period is why cut-off testing exists at year end.

Billing document types

Type Purpose
Invoice Standard bill
Credit memo Reduce what the customer owes (return, discount, error)
Debit memo Increase (undercharge, penalty)
Pro-forma invoice Not an accounting document — for customs, LC, or customer’s internal PO. No GL posting
Down payment request Ask for money before delivery
Cancellation Reverses a billing document
Intercompany invoice Between group entities
Collective / consolidated invoice Many deliveries → one invoice
Invoice list Many invoices → one statement for a payer
Self-billing (from customer) Customer sends you the invoice they’ll pay; you reconcile

Open items and clearing

Each invoice becomes an open item with a due date. It clears when payment is matched:

Invoice INV-1001  11,500   due 2026-04-15   OPEN
Payment received  11,500   2026-04-12
  → clear: both marked cleared, clearing doc created

Real life is messier:

Situation Handling
Customer pays less Partial payment (both stay open, linked) or residual item (new open item for the remainder)
Customer pays several invoices in one transfer Split the payment across items
Customer pays with unexplained deduction Dispute / deduction management — the residual becomes a dispute case with a reason code and an owner
Customer overpays Credit sits on account as an unapplied payment
Payment can’t be identified Goes to a suspense/unallocated account until resolved

Cash application

Matching incoming money to open items. The efficiency of this is a real business metric (“auto-match rate”).

Sources of payment data:

  • Bank statement (MT940, CAMT.053, BAI2, local formats)
  • Remittance advice (EDI 820, email, PDF)
  • Payment gateway / card settlement files
  • Direct debit collection results

Matching strategy, in order:

  1. Exact reference — the customer quoted the invoice number
  2. Structured reference — a checksum-bearing payment reference you printed on the invoice (Nordic KID, Swiss QR-bill reference, ISO creditor reference RF). If you can influence invoice design, add one; it takes auto-match from ~40% to ~95%.
  3. Exact amount against a single open item
  4. Combination matching — a subset of open items summing to the payment
  5. Fuzzy — customer name similarity + approximate amount
  6. ML models trained on the customer’s historical matching behaviour
  7. Manual

Credit management

Before you ship, should you?

Credit exposure =   open AR
                  + delivered but not yet invoiced
                  + confirmed orders not yet delivered
                  + open credit-relevant quotations (optional)
                  − credit insurance / LC coverage
                  − security deposits

Checked against a credit limit on the payer, in a credit control area (which may span several company codes). Exceeding it triggers a credit block on the order, delivery, or goods issue — configurable per document type.

Beyond the static limit, real credit management uses:

  • Risk category driving check strictness
  • Oldest open item age — block if anything is >X days overdue
  • Payment behaviour score — average days beyond terms (DBT)
  • External credit ratings (D&B, Creditsafe, local bureaus)
  • Dynamic limits from payment history

Blocked orders go to a credit manager’s worklist for release. Design note: the credit check must run at order save, delivery creation, and goods issue — exposure changes between them.

Dunning / collections

Systematic reminders for overdue items.

Dunning level  Days overdue  Action
1              7             Polite reminder email
2              21            Firmer letter, copy to sales rep
3              45            Final notice, block new orders, interest charged
4              60            Handover to collections agency / legal

A dunning run selects overdue items, computes the level per customer (usually the highest applicable across their items), generates correspondence, and stamps the level and date on the item. Config includes grace days, minimum amounts, dunning blocks, interest calculation, and per-customer dunning procedures.

Modern equivalents add: automated email/SMS sequences, self-service payment links, promise-to-pay tracking, and collector worklists prioritised by amount × risk.

Bad debt

When collection fails:

  1. Provision (allowance) — estimate of what won’t be collected, based on ageing buckets or an expected-credit-loss model (IFRS 9 requires forward-looking ECL, not just incurred loss) 
      Bad debt expense       Dr 50,000
 Allowance for doubtful accounts  Cr 50,000     ← contra-asset
  2. Write-off — a specific invoice is abandoned 
      Allowance              Dr 11,500
 Accounts receivable     Cr 11,500
  3. Recovery — if they later pay, reverse the write-off

IFRS 9’s expected credit loss model requires a provision matrix by ageing bucket and customer segment, updated each period. If you build AR reporting, the ageing buckets you produce feed this directly.

Deductions and disputes

Especially in retail supply, customers deduct from payments unilaterally: shortages, damages, promotional allowances, late delivery penalties, listing fees. Each deduction becomes a dispute case:

dispute_case(id, customer_id, invoice_id, amount, reason_code, status,
             owner, created_at, resolved_at, resolution)

Reason codes matter: they tell you whether the root cause is logistics, pricing, or the customer being opportunistic. Disputes are a leading indicator of operational problems elsewhere.

Payment methods

Method Notes
Bank transfer Slow to identify without a structured reference
Direct debit / ACH debit You pull the money — needs a mandate (SEPA DD mandate, ACH authorisation), with mandate ID and sequence type on each collection
Card Fees, chargebacks, tokenised card on file, PCI-DSS scope
Cheque Still large in the US and parts of Asia
Letter of credit Export trade; the bank pays on presentation of compliant documents. Document accuracy is everything
Mobile money bKash, Nagad, M-Pesa, UPI — dominant in some markets
Factoring You sell the receivable; derecognition rules apply

Key metrics

Metric Formula Meaning
DSO (AR / Revenue) × days in period Days sales outstanding — how long to collect
Best possible DSO (Current AR / Revenue) × days The floor if nothing were overdue
ADD / DBT Avg days delinquent / days beyond terms Lateness
CEI Collection effectiveness index % of available receivables actually collected
Ageing distribution % in each bucket Risk profile
Auto-match rate Auto-cleared / total receipts Cash application efficiency
Bad debt % Write-offs / revenue Credit quality

Data model 

ar_invoice(id, company_id, customer_id, payer_id, invoice_number, invoice_date,
           posting_date, currency, gross, tax, net, payment_terms, due_date,
           dunning_level, dunning_date, dunning_block, payment_block,
           status, sales_order_id, delivery_id)
ar_open_item(invoice_id, amount_open, due_date, cleared_by, cleared_at,
             dispute_case_id)
credit_master(payer_id, credit_control_area, credit_limit, risk_category,
              exposure_calculated_at, blocked)
dunning_run(id, run_date, company_id, status)

Next