SAP Accounts Receivable and Payable: Master Data and Business Partners (Part 1)
Book: Financial Accounting in SAP S/4HANA Finance Simplified: Questions & Answers by Narayanan Veeriah | ISBN 978-93-65898-675
Chapters 16 and 17 split accounts receivable and payable across two chapters. Part 1 (questions 445 through about 472) is the foundation: what AR and AP do in S/4HANA, how customer and vendor masters work, and the setup you need before creating a single business partner.
AR and AP in the bigger picture
FI-AR tracks everything customers owe you. It integrates with SD for sales, cash management for liquidity, dispute management, and collections. You get DSO reports, due date lists, dunning, automatic debits, and down payment handling.
FI-AP mirrors that for suppliers. Tight MM integration, payment program for outgoing payments, EDI support, DPO evaluation, payment blocks, and fraud management hooks.
Both are subsidiary ledgers. Postings hit AR/AP accounts and simultaneously update G/L through reconciliation accounts. No batch transfer needed. Real-time, always.
Key features the book highlights for each side:
| AR | AP |
|---|---|
| Master data shared with SD | Master data shared with MM |
| Open item monitoring | Invoice import |
| DSO evaluation | Cash discount forecasting |
| Correspondence (statements, dunning) | Payment proposal management |
| Periodic closing activities | Payment block and fraud checks |
Business partners replace the old world
This is a major S/4HANA shift. FD01, VD01, XD01, FK01, MK01, XK01 all collapsed into transaction BP. Customers and vendors are business partners with partner functions (sold-to-party, ship-to-party, goods supplier, invoice presented by, etc.).
Three default business partner types ship with the system. One partner can wear multiple hats. A customer who is also your vendor? Link them for clearing between customer and vendor during dunning and payment runs.
Customer master data areas:
- General data (client level): address, identification, shared across company codes
- Company code data: payment terms, reconciliation account, dunning data
- Sales and distribution data: sales areas, billing partners
- ETM data: engineering/construction industry specific
Vendor master mirrors this with purchasing organization data instead of SD data.
Maintain masters three ways: FI only, SD/MM only, or centrally for all areas. Your org structure determines which approach fits.
Prerequisites before creating masters
Three objects must exist:
- Number ranges (XDN1/OBAR for customers, XKN1/OBAS for vendors)
- Account groups (OBD2 customers, OBD3 vendors) controlling screen layout and numbering
- Field status (OB20/OB21 customers, OB23/OB24 vendors)
Account group is permanent once assigned. Plan groups for regular accounts vs one-time accounts at minimum.
Reconciliation accounts and special fields
Reconciliation accounts in G/L are the bridge. Every customer/vendor posts to a recon account that keeps G/L balanced. You define currencies and posting screen controls through recon accounts.
Special fields worth knowing:
- Accounting clerk: sorts dunning and payment proposals, prints on correspondence
- Trading partner number: inter-company elimination during consolidation
- Alternative payee/payer: pay or collect through a different business partner
- Customer-vendor clearing: link accounts in general data, enable clearing checkboxes in company code
- Group and search term: group reporting and fast lookup
Alternative payers have three selection modes: default from master, pick from permitted payers list, or propose new payer at document entry (document-level payer wins over master).
Dual control protects sensitive fields like payment terms. Changes need a second approver or the account blocks in payment run.
One-time accounts, blocking, and archiving
One-time customer/vendor accounts are genius for occasional trading partners. One master record covers many actual parties. Name, address, and bank details enter at invoice posting, not in the master. Saves master record clutter and disk space. Separate reconciliation accounts help distinguish one-time domestic vs overseas suppliers.
Blocking prevents future postings or orders. Critical rule: do not block accounts with open items you still need to clear. Block at company code or central level. Transaction codes: FD05/XD05 (customer), FK05/XK05 (vendor).
Archiving/deletion requires zero transaction figures plus deletion flag (FD06/XD06, FK06/XK06). Block first, then mark for deletion, then archive.
Payment terms and cash discount base
Payment terms like “15 Days 3%, 30/2%, 60 Net” define credit period and early payment discounts. Same terms can serve customers and vendors. Maintain in master records, system applies during payment processing.
Cash discount base for incoming invoices: net (excludes tax and freight from discount calculation) vs gross (full invoice amount). Configure via IMG or OBY6 company code parameters.
Payment program preview
Part 1 ends as the payment program discussion begins. Global settings for outgoing payments cover cash discount accounts (OBXU, OBXV), over/underpayment accounts (OBXL), exchange rate differences (OB09), rounding (OB00), bank charges (OBXK), clearing posting keys (OBXH), translation posting (OB66), and payment block reasons (OB27).
Manual outgoing payment scenarios: direct payment without invoice, or payment of vendor open line items. Prerequisites: house banks, bank accounts, payment methods, payment forms.
Part 2 goes deep on FBZP configuration, payment runs, SEPA, and payment advice notes.
Previous: SAP General Ledger Part 2 | Next: Accounts Receivable and Payable Part 2