Business Partners: Customers, Vendors, and Partner Functions

The old model vs the new model

Old (still everywhere): separate Customer master and Vendor master, with separate number ranges and separate screens. If a company is both your customer and your supplier, it exists twice with no link.

New (Business Partner / BP model): one partner record with roles. The same legal entity can be a Customer, a Vendor, an Employee, a Bank, a Carrier, and a Competitor at once.

Business Partner 100455 — Rahman Textiles Ltd
├── Role: Customer  → payment terms, credit limit, price list, sales area data
├── Role: Vendor    → payment terms, bank details, purchasing org data
└── Role: Carrier   → transport data

SAP S/4HANA made BP mandatory (customer/vendor screens were retired). NetSuite, Dynamics, and Odoo all use a unified “party” concept. If you’re building your own ERP, start with a unified party model — retrofitting it is brutal.

The party data model 

party (id, type: ORGANISATION|PERSON, name, tax_id, country, ...)
 ├── party_role (party_id, role: CUSTOMER|VENDOR|EMPLOYEE|CARRIER|BANK, valid_from, valid_to)
 ├── party_address (party_id, type: BILL_TO|SHIP_TO|REMIT_TO|LEGAL, address..., valid_from)
 ├── party_contact (party_id, name, email, phone, function)
 ├── party_bank_account (party_id, iban/acct, swift, currency, valid_from)
 ├── party_identifier (party_id, scheme: VAT|GSTIN|DUNS|GLN|BIN, value)
 └── party_org_data (party_id, company_id / sales_org / purch_org, role-specific attributes)

That last table is the key: role attributes are per organisational unit, exactly like the material master. The same customer can have different payment terms in your UK entity and your Bangladesh entity.

Customer master: what’s actually on it

Group Fields
General Name, legal form, tax ID, industry, addresses, contacts, language
Company code (accounting) Reconciliation account, payment terms, payment method, dunning procedure, house bank, tolerance group, withholding tax
Sales area Sales district, price list, currency, incoterms, delivery priority, shipping condition, partial-delivery rules, tax classification, account assignment group
Credit Credit limit, risk category, credit control area, payment history
Output How they get documents — print, email, EDI, portal
Partner functions See below

Partner functions — a concept people miss

A single sales order involves several different parties:

Function Meaning
Sold-to (SP) Who placed the order — the commercial relationship
Ship-to (SH) Where the goods go
Bill-to (BP) Who receives the invoice
Payer (PY) Who actually pays (and whose credit limit is checked)
Carrier Who transports
Employee responsible Sales rep
Forwarding agent Freight forwarder

Real example: a retail chain’s head office is Sold-to and Payer, each of 60 stores is a Ship-to, and a shared services centre is Bill-to.

Vendor side has the mirror set: Ordering address, Invoicing party, Goods supplier, Remit-to.

Design rule: put partner functions on the document, not only on the master. The document snapshots which partners applied at the time.

Account groups / partner types

Controls number range, field status (what’s mandatory), and which views exist:

  • Domestic customer / Foreign customer
  • One-time customer (a shared record for walk-ins; the actual name and address are stored on the document)
  • Intercompany customer/vendor
  • Employee vendor (for expense reimbursement)
  • Prospect (no transactions yet)

One-time accounts are worth knowing: instead of creating 40,000 master records for retail walk-ins, you use a single generic master and store the address on each document.

Hierarchies

Customers form hierarchies for pricing, rebates, and credit:

Global Group (rebate agreement level)
 └── Regional buying group (price list level)
      └── Legal entity (credit limit level)
           └── Store / ship-to (delivery level)

The hierarchy node is a real object with its own pricing conditions. Buying groups in retail and grocery make this essential.

Data quality: duplicates

Duplicate business partners are the single most common master data defect. Consequences: split credit exposure, missed volume discounts, wrong dunning, failed statutory reporting.

Detection strategies:

  1. Hard keys first — tax ID (VAT/GSTIN/BIN), DUNS, bank account, registration number
  2. Normalised name matching — strip legal suffixes (Ltd, Limited, Pvt, GmbH, S.A.), lowercase, remove punctuation
  3. Fuzzy — trigram/Levenshtein on normalised name + postcode match
  4. Block on create, review queue on import

Merging duplicates after transactions exist is painful: you cannot re-point posted documents in most ERPs, so you block one and carry both in reporting via a “successor” link.

Compliance screening

Before you transact with a party, regulated businesses must check:

  • Sanctions / denied party lists (OFAC, EU, UN, UK HMT)
  • Embargo by country
  • KYC/AML for financial services
  • Tax residency and withholding status (W-8/W-9 in the US)
  • Politically exposed persons for some sectors

In ERP this appears as Global Trade Services / trade compliance checks that block order creation or delivery until cleared. If you build the customer-create API, this check belongs in it, not in the UI.

Payment terms

A small object with outsized importance. Attached to both customer and vendor, defaulted onto every document.

Code   Description               Net days  Discount
NET30  Net 30 days               30        —
2/10N30  2% if paid in 10 days   30        2% / 10 days
EOM45  45 days end of month      45 (from month end)
CIA    Cash in advance           0
LC90   Letter of credit 90 days  90

Terms drive: due date calculation, cash discount, ageing buckets, dunning, cash forecast, and the discount GL posting. Baseline date can be document date, posting date, entry date, or goods-receipt date — a config choice that changes every due date in the system.

Practical rules

  1. Unified party model from day one.
  2. Never hard-delete a partner. Block for posting/order/delivery/billing separately.
  3. Address history matters — invoices must reprint with the address used at the time. Effective-date addresses or snapshot them.
  4. Tax ID is not unique globally — a party can have registrations in several countries. Model it as a list, not a column.
  5. Bank details are a fraud target. Changing a vendor bank account must be a workflow-approved, dual-control, fully audited action. Vendor bank fraud (BEC) is one of the most common corporate losses; your change screen is the control point.

Next