Before signing an agreement, request a real, verifiable sample of exported business data. Do not accept only a file list or a screenshot. The sample should include records, their relationships, associated attachments, and a data dictionary. The outcome of the test is not a received file, but the ability to reuse business records in the agreed business process.
Changing suppliers is not the only point at which this matters. The same test helps when selecting a new ERP, connecting systems, separating a company, introducing analytics, or transferring maintenance to another partner. Data transfer then becomes a business decision supported by technical evidence, rather than a contract item left in the background.
A file can contain many rows and still be unusable. Without identifiers, relationships, and field meanings, a new system or team may struggle to establish what each record represents, what it belongs to, and in what sequence it was created.
For example, a list of invoices without customers, line items, tax codes, currencies, statuses, and a link to the original document is not a complete business record. The same applies to a production order without a bill of materials, operations, consumption records, and traceability of related documents. An attachment without a clear link to a record may remain only a file in a folder.
This is why business data export verification should answer four questions:
Business record portability is not the same as downloading one table. It is the ability to use data outside its source system with enough context for work, verification, and transfer of responsibility.
Request a limited sample that is real enough to test and proportionate to the decision. The sample does not need to contain the full database. It should cover one completed business flow and its edge cases.
For ERP and accounting, this could be a selected set of sales invoices with customers, line items, payments, postings, and attachments. For manufacturing, it could be a closed production order with materials, operations, quality documents, and related inventory movements. The scope depends on the process the organisation must be able to continue after the change.
Request the following inputs from the supplier:
A data dictionary is not decorative documentation. It defines the meaning of fields such as status, date, quantity, amount, or document code. Without it, the recipient may load a file technically while interpreting it incorrectly in business terms.
The two verification layers serve different purposes. The first tests data structure. The second tests whether the record can be reused in work.
First, verify that records exist and can be linked to one another. Unique identifiers, required fields, and referential links matter here. Data constraints can verify uniqueness, required fields, and relationships between records. PostgreSQL describes such constraints, including primary, unique, and foreign keys, in its Constraints documentation.
For the sample, record at least:
These checks do not confirm business correctness. They show whether the data set can be linked and controlled technically.
After structural verification, trace several records through the full flow. For each selected invoice, order, or document, verify whether the responsible business person can answer basic questions without access to the source system:
This does not have to be a full migration test. It is evidence that the export carries enough context for the agreed reuse. If the future destination has not yet been selected, the test can end with a controlled review in a neutral tool and documented rules required for later loading.
Consider a company that wants to verify a sales invoice export before entering into an agreement. It selects several invoices with different statuses, including one with a credit note and one with an attachment.
A useful sample does not end with a CSV file of invoices. It includes customers, invoice headers, line items, tax codes, recorded payments or open items within the agreed scope, links between those sets, and an attachment list. The data dictionary explains status codes and how reversals or credit notes are marked.
The team then verifies whether it can find the customer, line items, and related attachment for every selected invoice. If an invoice refers to a customer that does not exist in the export, that is an exception. If an attachment can be retrieved but has no reliable link to the invoice, that is another exception. If a status label is not explained, that is a documentation gap even where the file format is technically readable.
Such a scenario does not prove the quality of every future export. It shows what the agreement, transition plan, and acceptance criteria need to cover precisely.
Structural constraints are useful for finding obvious issues, but they do not replace business rules. A system can confirm that a reference exists, but it cannot decide on its own whether an invoice may be issued without a specific internal review, whether an order should remain open, or which code is permitted for a particular transaction type.
Define business rules separately. For every important rule, record:
This list protects both sides from an unclear expectation that technical verification will automatically resolve business interpretation.
Verification stalls when every party expects someone else to define scope, confirm data meaning, or decide on an exception. Name an owner for every input.
The customer usually owns the decision on business scope, priority processes, record retention, and acceptable exceptions. The source supplier usually owns the technical export method, source description, known limitations, and delivery of the agreed sample. The future data recipient, whether an internal team or a new partner, confirms whether the sample can support the agreed reuse.
It is useful to separate day-to-day collaboration, official ERP transactions, and specialised engineering work. This separation reduces the risk of resolving a question of business meaning through a technical decision alone, or the reverse.
Where process scope is still unclear, Business process screening can help establish which records, decisions, and transitions matter most.
An acceptance criterion such as "the file was delivered" is insufficient. Connect acceptance to verifiable work on the sample.
One measurable acceptance criterion can state: the responsible business person and technical reviewer document that, for every record in the preselected sample, they can find related records and attachments, interpret required fields according to the data dictionary, and record every unsupported link, missing attachment, or unclear value as an exception.
The measure is not an invented percentage. It is a record of the verified sample, found relationships, open exceptions, the owner of each exception, and the decision to resolve or accept it. Sample scope and permitted exceptions should be agreed before the export.
Before signing, bring together the owners of data, process, and technical verification, and confirm the following:
Requesting a sample before an agreement does not remove the need for a transition plan. It creates a basis for a realistic plan: known scope, visible dependencies, named owners, and verifiable evidence of business record portability. If your organisation first needs to separate process priorities from technical assumptions, start with Business process screening or talk to the ORKA team about the verification scope.