Down Payment Request, Payment and Clearing in the Final Invoice
The customer pays 20% up front: a down payment request is billed from the order's billing plan (a noted item, not revenue), the payment is posted as a down payment received, and the final invoice deducts it and clears it.
Educational content. SAP behaviour varies by configuration and release. Spotted something off? Report it.
Digital twin
01Order with a down payment agreement
Order 10000310 for ₹2,00,000; the billing plan contains a 20% down payment date.
Business scenario
Demo Retail orders 100 EA of FG-2000 for ₹2,00,000 and agrees to pay 20% (₹40,000) before production of the shipment is scheduled.
All companies, numbers and documents are fictional demo data.
Step-by-step flow
- 01
Order with a down payment agreement open in twin
Order 10000310 for ₹2,00,000; the billing plan contains a 20% down payment date.
That date makes the down payment request due for billing.
- 02
Bill the down payment request (FAZ) open in twin
Down payment request for ₹40,000 sent to the customer. It is a noted item: no revenue, no receivable yet.
Revenue must not be recognised for goods not yet delivered; the request only reminds and tracks.
- 03
Customer pays the down payment open in twin
₹40,000 received and posted as a down payment — a liability to the customer until the goods ship.
Until delivery, the money belongs to the customer in accounting terms.
- 04
Deliver the goods open in twin
100 EA ship; goods issue posts cost of goods sold.
Delivery makes the final invoice due.
- 05
Final invoice open in twin
The full order value is ₹2,00,000. What does the final invoice ask the customer to pay?
The down payment condition (e.g. AZWB, typical) copies the received amount into the invoice.
- 06
Customer billed twice open in twin
Invoicing the full ₹2,00,000 ignores the ₹40,000 already paid; the down payment stays open as a liability.
The customer disputes the invoice and FI has an open liability that should have been cleared.
- 07
Final invoice clears the down payment open in twin
Revenue ₹2,00,000; the down payment ₹40,000 is cleared; ₹1,60,000 remains to be paid.
Customer account: ₹1,60,000 open; down payment account: zero.
- 08
Down payment settled open in twin
Order → down payment request → payment → delivery → final invoice with clearing.
This keeps revenue recognition tied to delivery while securing cash early.
SAP documents
Stock impact
| Step | Plant / SLoc | Stock type | MvT | Change |
|---|---|---|---|---|
| Deliver the goods | 1000 / 0001 | Unrestricted use | 601 | −100 EA |
Accounting impact
Down payment received
TypicalCustomer pays the down payment
- Dr Bank₹40,000
- Cr Customer down payments received (special G/L A)₹40,000
The customer line uses a special G/L indicator, so it posts to a down-payments-received reconciliation account (a liability), not to normal receivables.
Goods issue
TypicalDeliver the goods
- Dr Cost of goods sold (GBB/VAX)₹1,20,000
- Cr Inventory — finished goods (BSX)₹1,20,000
Standard COGS posting.
Final invoice
TypicalFinal invoice clears the down payment
- Dr Customer receivable₹2,00,000
- Cr Revenue — domestic sales (ERL)₹2,00,000
Full revenue and receivable.
Down payment clearing
Configuration dependentFinal invoice clears the down payment
- Dr Customer down payments received (special G/L A)₹40,000
- Cr Customer receivable₹40,000
The down payment received is transferred against the receivable, leaving the net amount open. Whether this happens in billing or in a separate FI clearing step (F-39) is configuration dependent.
Typical conceptual flow. Actual G/L accounts and posting behaviour depend on material valuation, automatic account determination and system configuration.
Movement type
- 601GI for deliveryReversal: 602
Secures part of the payment before delivery while keeping revenue recognition tied to the actual sale.
Transactions & Fiori apps
- VA01 — Sales Order with Billing Plan
- VF01 — Down Payment Request / Final Invoice
- F-29 — Post Customer Down Payment
- F-39 — Clear Customer Down Payment
- Create Billing Documents
Differences by SAP version
Billing plans, FAZ and AZWB as described.
Same SD logic; FI down payments in the universal journal.
Down payment processing in sales is scope dependent.
Configuration
Billing plan type and billing rule for down payments
Configuration dependentDefines dates, percentages and the down payment rule.
Special G/L accounts
Configuration dependentDown payment received and request accounts per reconciliation account.
Prerequisites
- Item category with a billing plan for down payments
- Billing type FAZ and down payment condition (AZWB, typical)
- Special G/L indicators A (down payment) and F (request) configured
Master data
- Customer
- Reconciliation account and special G/L setup.
Organizational structure
- Company code 1000
- Sales area 1000/10/00
Tables
| Table | Description |
|---|---|
| FPLA / FPLT | Billing plan and billing plan dates |
| VBRK | FAZ and F2 billing documents |
Integration
- FISpecial G/L postings for requests and down payments; clearing at final invoice.
Common errors
“Down payment not deducted in the final invoice”
Likely causes: Payment not posted against the request; Down payment condition missing in pricing
Where to look: Customer special G/L items · Pricing procedure
Troubleshooting
Something went wrong? Work through these checks in order. They are diagnostic questions, not configuration instructions — confirm changes with your system owner.
CHECK 1
Clearing
- Is the payment posted against the request?
- Is the down payment condition in the final invoice?
Interview questions
How are down payments handled in SD?
A billing plan date triggers a down payment request (FAZ), posted as a noted item. The customer's payment is posted as a down payment received with a special G/L indicator (a liability). The final invoice recognises full revenue and the down payment condition deducts the paid amount, which is cleared against the receivable.
Quiz
References
- SAP SE — SAP Help Portal: Down Payment Processing in SD (source)
- SAP SE — SAP Help Portal: Billing Plans (source)
Explanations are original. They summarize standard behaviour; always validate against your system's release and configuration.
Version history
| Version | Change |
|---|---|
| 1.0.0 | Initial version. |