A customer code change in an integration is not merely an update to one ERP field. A safe process maps the old and new identifiers, checks every reference that uses the code, and clearly separates a technical rename from a merge of two real business entities. The history of orders, invoices, deliveries, open items, and messages sent to connected systems must remain understandable after the change.
A customer code often has more than one role. It may be a business-visible label on a document, a key for data exchange, a value in a report, or a reference in another system. A change can therefore affect several processes, even when a user sees only one field in the interface.
The first question is not "how do we change the code?" It is "what does the new code represent?"
There are two distinct cases:
These cases should not use the same process simply because both result in one active code. A technical rename requires continuity of identity. A merge requires a business decision on which records belong to which entity and from which point in time.
For a technical rename, maintain an explicit mapping between the old and new identifiers. The minimum record includes:
The mapping is not merely a supporting spreadsheet for the project. It is the business evidence of how systems interpret historical and new messages. If an integration receives the old code after the transition, the system needs predefined behaviour: accept and translate it, reject it with feedback, or route it for manual handling. The answer depends on the process, the agreed exchange method, and the risk of incorrect posting.
Where architecture permits, it is useful to separate a business code from a permanent technical identity. A visible code change then does not automatically alter every connection to related records. This is not a universal solution for existing systems, but it is a useful question when designing the change.
The reference inventory needs to cover more than the primary customer record. Check at least the following groups:
This list does not claim that every ERP has the same objects. Its purpose is to direct the review toward places where an identifier may appear as a key, an attribute, or a text value.
Data constraints can help verify uniqueness, mandatory fields, and relationships between records. PostgreSQL, for example, describes constraints such as UNIQUE , NOT NULL , primary keys, and foreign keys in its Constraints documentation. Such checks do not determine the business meaning of the change. The rule for accepting an old code, the period of parallel operation, or whether records may be merged must be defined separately and have a named owner.
Before technical preparation, bring together the master data owner, finance, the sales process owner, the integration owner, and the person responsible for ERP transactions. Then answer the following questions.
Hypothetical scenario: a customer changes its internal label from K-104 to K-778 , with no change to the business entity. The mapping register links both labels to the same permanent identity. New sales documents use K-778 , while historical documents may retain the originally recorded label if that is the business rule. The integration must then recognise which label the partner sends and record the processing result.
A second hypothetical scenario involves two records created through duplicate entry. This is not automatically a rename. Before a merge, review the business data, open transactions, and reporting effects. Where the entity identity is uncertain, keep the record as an exception until a business decision is made.
A practical sequence reduces the risk of disruption and incorrect linking of historical records.
Automatic routing of an old code may ease the transition for partners, but it can also hide outdated configuration. Strict rejection of an old code exposes the problem sooner, but can stop a business flow. A period of parallel acceptance is therefore not merely a technical setting. It is a process-owner decision based on the impact on transactions and support.
The same applies to changes in historical documents. Displaying the new code across all history supports a unified customer view. Retaining the original code preserves the document context at the time of creation. Decide what users need to see in operational work, reporting, and variance analysis.
When scope is unknown or responsibilities are unclear, Business process screening can structure owners, flows, and decisions before a technical change.
Prepare these inputs before work starts:
Assign responsibilities:
Record exceptions such as an unknown old code, conflict with an existing new code, multiple possible destinations, a missing mandatory value, and an unresolved merge decision.
An acceptance criterion can be verifiable without an arbitrary target number: every record in the approved scope must have one clearly recorded decision, every tested reference must resolve according to the approved rule, and every exception must have an owner and a status. The customer code change then becomes a managed process for linking historical records rather than an isolated field update.
For a process involving multiple ERPs or unclear data ownership, the next step is a joint review of flows and responsibilities with the ORKA team .