Orders, ship notices, invoices and remittances as Governed Data Records, composed from open standards. The meaning travels with the record. Whatever format a partner mandates is a projection of it.
Scheduled for the first quarter of 2027. The business documents library, composed from the OASIS Universal Business Language and GS1 identifiers on the published Default and ProvGov libraries, and a clone-and-run demonstration: a supplier and a retailer exchanging a year of orders, ship notices and invoices, and a deduction that survives a question. The components and the demonstration are published when they ship.
This is the data layer. Business Data Exchange represents your B2B transactions as SDC data. When an exchange needs a record both sides can verify, see the Verifiable Settlement Layer, which settles a change of state against the model and issues a receipt anyone can check offline.
Moving a business document between two companies has been nearly free for twenty years. Agreeing what it means is paid for again with every partner and every change.
A document format defines the fields. What a field means in a given relationship is written in the partner's guide, and the supplier keeps one map per partner, renegotiated whenever either side changes anything.
The last mandated version step of the US healthcare transaction standards was costed by the regulator at 25 to 50 percent of the original build, with testing at 60 to 65 percent of that. Industry assessed the next one at two to four times the effort of the last.
A product arrives as a buyer part number, a GTIN or a marketplace code depending on the partner, and nothing in the document says which system issued it. The supplier's cross-reference spreadsheet is the only place they meet.
The document vocabulary is not the problem, and it does not need inventing. The OASIS Universal Business Language defines the order, the order response, the despatch advice, the receipt advice, the invoice, the credit note and the remittance advice as an OASIS Standard, royalty-free and freely available; it is the basis of European e-invoicing and the Peppol network. GS1 defines the identifiers of products, locations and shipments. What those standards leave outside the document is the same thing every format leaves outside it:
A schema says a field is a string of up to eighty characters. It does not say, in a form a machine can resolve, which concept the field is an instance of, what it may hold, and where that definition came from.
Who produced the document, from what, under which version of the partner's rule, whether it conformed before it was sent, and a settlement record both parties can verify afterward. Today those live in logs, emails and a dispute.
For a worked account of where that cost lives in the standard most US supply chains still run on, read the implementation guide: where EDI's recurring cost lives.
Model the business documents once from open content. Keep the record. Emit whatever a partner mandates as a projection of it.
The order, order response, despatch advice, receipt advice, invoice, credit note and remittance advice, modeled from the OASIS Universal Business Language and composed by identifier slot from the published Default library (organizations, addresses, money, quantities, dates) and ProvGov library (provenance, audit, the order's state). Product, location and shipment identifiers as GS1 issues them, each carrying the system that issued it.
Order → Default organization + address + money, ProvGov activity + audit + order workflow
Every value in a record is an instance of a published component: a permanent identifier, a definition, its constraints and units, and links to the vocabulary that defines the concept. A partner who receives the record resolves the definition instead of reading a guide. Two partners who compose the same component agree because they reference one definition, not because two guides happen to align this year.
Requested Delivery Date → one component, one definition, every partner
Beside its data, every record carries the activity that produced it, the agent, the document it came from, and an audit event, bound at the source. It is validated against its published model before it is sent, and each change of the order's state settles against the model's workflow with a receipt that names the model version and can be verified offline by a party who runs none of our software.
deduction → which rule version, what it required, did the notice conform, when
Nothing here replaces the network, the transport or the format a partner mandates. The Governed Data Record becomes the system of record; the translator you already run writes the partner's format from it and reads the partner's documents into it, inside your own environment. Move one partner at a time. Stop emitting a format when the partner accepts the record.
record → table, XML, graph, and the partner's wire format, all projections
UBL documents on the Default and ProvGov libraries
Validated once, projected as table, XML and graph
Your translator, your environment, one partner at a time
Refused before transmission; receipted on every state change
Where the cost lives today, and the demonstration that shows the alternative.
The meaning of a document lives in the partner's guide, so agreement is rebuilt per partner and per change. Where that happens, with the three cost figures that survive sourcing.
A fictitious food manufacturer takes a three percent deduction for a ship notice that both systems processed correctly, because a rule and an identifier changed on dates the notice did not carry. Two clone-and-run stacks, a supplier and a retailer, a year of orders as Governed Data Records, and the deduction settled against the model with a receipt. Published when it ships.
B2B scenarios where the meaning travels with the record
Order, order response, despatch advice, invoice and remittance as one chain of Governed Data Records, each composing the same components, each settled with a receipt.
One purchase order model across every retailer a supplier sells to; each retailer's mandated format a projection written by the supplier's own translator.
Order, receipt advice and invoice matched on the components they share rather than on fields reconciled by hand, with the match itself a settled state.
A despatch advice validated against the retailer's published rule before it is sent, and a deduction that names the rule version, what it required and whether the notice conformed.
One product record carrying every identifier it has been issued, GTIN, SKU, buyer and vendor part numbers, each with its issuing system named.
Every record states who produced it, from what and when, projected into a knowledge graph a third party can query without a reconstruction project.
The structural claim, for a company integrating with many trading partners
Each party binds once to the shared components instead of negotiating a private interpretation with every other partner.
A published component is immutable, so a new version is an addition. Documents already exchanged stay valid against the version that governed them.
Bound to the record, not described in a guide that each partner reads differently.
The work scales with the number of relationships, not with the number of documents.
The work scales with the number of concepts, which is finite and shared.
Why there are no dollar figures here
This page used to carry a five-year model for this exact scenario, with per-line annual costs on both sides, a total saved, a percentage and a payback period. We removed all of it, because we could not source any of it. What a map costs depends on the documents in scope, the partner's guide, and what your hub charges, and those vary far too much for one modeled supplier to stand in for yours.
The structural claim does not need the model, and it is the one worth testing: the cost of integration scales with how many partners you have, because the meaning lives in a document each of them interprets privately. Bind the meaning to the record and it scales with how many concepts you exchange instead. You already have the numbers to check that. Count your active maps, and ask what you paid to change one last year.