Blog · Data quality and reconciliation
Distinguish order customer, invoice recipient, delivery location and documented contracting entity, with a synthetic invoice and no duplicated revenue.
An order names a branch, its invoice goes to a shared finance center and its goods arrive at two warehouses. Which one is the customer? The answer depends on the question. Delivery planning, collections, account coverage and contract renewal may need different roles.
This page owns the role comparison. The contracting-entity glossary retains the meaning of contracting entity, and the account hierarchy guide explains parent/site roll-ups. A field named bill-to does not by itself establish who signed an agreement.
A sold-to or order-customer role identifies the party associated with ordering or sales processing under the system's configuration. Bill-to identifies the invoice recipient/account used for invoicing. Ship-to identifies the delivery party or location. A separate payer role may identify settlement responsibility.
ERP labels and configurations vary. SAP documents distinct sold-to, ship-to, bill-to and payer functions and allows one customer to hold several roles or different partners to hold them. Microsoft Dynamics 365 also documents that the invoice account can differ from the order customer. SAP partner functions, Microsoft customer and invoice accounts.
These sources establish the possibility of distinct operational roles. They do not determine the legal signatory to a particular agreement or guarantee that every export uses identical field names.
For each source field record its meaning, source table, document level, identifier domain, effective-date behavior and whether it is a partner entity or an address. A ship-to address ID may identify a delivery point within one entity; it should not automatically become a new legal customer.
Keep the original source company, document ID and line ID. Store role identifiers separately from display names. If a customer holds two roles, that should be two role relationships to the same identifier, not two revenue transactions.
Use an explicit evidence reference for the contracting entity selected by the authorized owner. The signatory decision record captures that decision; it does not infer signatory from the invoice address.
Invoice I-500 belongs to one order with two lines and $12,000 total net revenue. The reviewed agreement identifies E-100 as the contracting entity. These fictional roles are preserved on the transaction.
| Role | Identifier | Interpretation for this example |
|---|---|---|
| Order customer / sold-to | C-10 | Branch placing the order |
| Bill-to | B-20 | Group invoice-processing account |
| Payer | P-30 | Shared settlement entity |
| Ship-to, line 1 | W-01 | Warehouse receiving $7,000 of goods |
| Ship-to, line 2 | W-02 | Warehouse receiving $5,000 of goods |
| Contracting entity | E-100 | Entity established by reviewed agreement evidence |
The revenue identity is $7,000 + $5,000 = $12,000. A contracting-entity view assigns $12,000 to E-100. A delivery view shows $7,000 at W-01 and $5,000 at W-02. These are two views of the same amount, not $24,000 of revenue.
A bill-to total of $12,000 answers where the invoice is directed. It does not establish that B-20 owns the renewal decision or that both warehouses buy independently. Those conclusions require the selected business relationship and evidence.
A corporate parent is a hierarchy relationship, while bill-to or ship-to is a role on a transaction. A shared billing entity may process invoices for several independent contracting entities. Conversely, one contracting entity may operate many ship-to locations.
Do not use the corporate parent as a universal substitute for signatory. Keep dated parent relationships for the chosen group view, and preserve document-level roles. The mapping workbook can connect source identifiers to reviewed entities without erasing those roles.
For healthcare-specific delivery mapping, the existing facility-identifiers guide remains the application owner. This role comparison should not become another sector hierarchy article.
Check that every revenue line has at most one selected contracting-entity attribution under the reporting policy. Record missing or conflicting evidence as an exception. Do not fan a full invoice-header amount out to every delivery location or partner-role row.
Test a bill-to differing from sold-to, multiple delivery lines, changed invoice recipient, cross-company identifiers and a branch ordering under its own agreement. A current master-data role may differ from the role saved on an old order; decide which history the report uses and label it.
Changing a display name should not restate historical revenue attribution. Changing the approved signatory mapping might, and that requires a dated decision and a versioned report.
Collections usually needs the invoicing/settlement relationship; logistics needs delivery roles; contractual coverage and renewal analysis need the documented contracting relationship. Show the chosen role in the report heading rather than calling every dimension Customer.
Bring an authorized order/invoice example and source field definitions to discuss a reporting scope. This method does not promise automatic legal-entity verification or a connector to every ERP.
No. The invoice recipient can differ from the order customer or documented signatory. Establish contracting attribution from approved agreement evidence.
It creates two delivery relationships. Whether they are independent contracting customers requires separate evidence; revenue must still reconcile once.