An integration works reliably only when both systems interpret every business data item in the same way. A business data contract therefore describes more than a message format. It defines the meaning of integration fields, permitted values, units of measure, required values, change ownership and the response to an invalid record.
Without that agreement, two technically connected systems can exchange messages while the business process still creates incorrect orders, inventory records or postings. The issue is often not the connection itself, but a different interpretation of data.
A technical specification usually lists a field name, data type and transfer method. That is a necessary start, but it does not resolve the business decision. A quantity field may be a number with two decimal places, yet it remains unclear whether it represents pieces, kilograms, metres or packages. A customer_id may have a valid format but belong to a customer who is not approved for orders.
A business data contract connects technical exchange with business meaning. For each field that affects the process, document at least:
This record serves the people who run the process, ERP users and engineers who maintain the integration. Its value lies in removing unstated assumptions before they become operational incidents.
First determine which decision the data supports. In an order handover, decisions may concern order acceptance, item availability, delivery, invoicing or posting. Only then does it make sense to agree on fields and technical transfer.
A useful sequence of work looks like this:
The owner of an input is not necessarily the owner of the whole process. A customer relationship system may be the source of customer contact data, while ERP remains the official source for a customer's accounting status. The contract must clearly separate who may create a value, who may change it, and which system publishes the official state for each decision.
The following scenario is hypothetical. It is a workshop pattern, not a description of a specific ORKA solution or customer.
A sales system sends an order to ERP when a sales user confirms the handover. For the order header, the contract could define these data items:
For every line, the contract could define:
Here, the unit of measure is not an optional addition to quantity. A quantity of 12 without a unit does not tell ERP whether it receives 12 pieces, 12 kilograms or 12 packages. Where systems use different unit code lists, the contract should include the mapping, the owner of that mapping and the change procedure.
Assume the sales system sends a line with an item and quantity but without unit_of_measure . The receiver should not create a partial order or infer the unit. It should reject the entire record or, where agreed, only the invalid line. The choice depends on whether the process permits partial processing.
The receiver's response should include enough information to correct the issue without searching technical logs:
The message should not shift business interpretation to an ERP user. If the receiver accepts only complete orders, the sender needs to see that rule before sending, and the rule needs to be testable during integration acceptance.
Database constraints can validate uniqueness, required values and relationships between records. PostgreSQL, for example, documents constraints such as NOT NULL , UNIQUE , PRIMARY KEY and foreign keys: PostgreSQL Constraints .
These checks matter, but they do not replace business rules. A rule such as "a customer may order only items in an approved assortment" or "an order in a given status requires manual review" needs a separate definition. The contract must state where the rule is enforced, who decides on an exception and what response the system returns.
This separation reduces two common mistakes. The first is trying to put every business decision into technical validation. The second is leaving basic data quality only to user instructions. A technical constraint, a business rule and an operating procedure have different responsibilities, even when they protect the same process.
A change to an item code, unit of measure, field requirement or status meaning can change the process outcome without changing the connection between systems. The contract should therefore include a change procedure:
It is useful to maintain a contract version and link it to the business event, not only to a technical release. This allows the team to identify which rules were used to process older orders.
Before accepting a business data contract, use this checklist:
If the answers are not clear, begin with a Business process screening . It can establish where the business decision occurs, which system carries the official transaction and which exceptions need an operating procedure. The data contract then becomes a practical tool for connecting systems, rather than a document opened only after an error occurs.