Most reporting projects fail not because of technology, but because of unclear input of source data. A data contract is the agreement that precedes this.
The management report has been running for three years. The numbers are good, no one complains. Then a colleague from controlling leaves — and suddenly no one in the company can say why projects with the mask D1 and not D4 are being selected, or why one cost type is being omitted from the total. This is not an exception. This is the most common way in which reporting is built in our country: someone set the parameters once, the result was good, and it has been repeated ever since. The instructions live in Excel on their disk, or in their head.
Analysis describes the state. A contract is an agreement
A data contract is not another technical document. It is agreement between the person who supplies the data and the person who builds the report from it. One party guarantees the content, structure and delivery date. The other guarantees the transformations, calculations and availability of the output.
The difference is significant. You read the analysis and put it aside. The contract has an owner, a version, and a change process — and when the project mask changes, it's clear who has to approve it and what it will cause.
What must be in it?
Seven parts, without which it is just a nicely formatted document:
- Report identification — purpose, granularity, frequency, and most importantly what is outside This sentence will save you the most arguments.
- Source extracts with codes E01, E02… Everything else refers to those codes.
- Selection parameters — the exact values that are entered when running the report.
- Data dictionary — what columns the extract should contain, what type, and whether they are mandatory.
- Business rules with its own ID, referenced by both code and testing.
- Quality controls — which verifies that the report matches the source.
- Schedule and responsibilities — who, what, until when.
The detail that makes the difference
If you were to fill in only one section, these are selection parameters. Fiscal year, period, cost type group, project masks, order groups. It sounds boring, but without them, the extract cannot be repeated and the whole reconciliation relies on someone remembering it.
The second thing that breaks down is business rules with exceptions. "Sum of all cost types 813xxx" is not a rule. "Sum of 813xxx except 813400, which is part of the division's performance, is already there. It is precisely those exceptions that no one writes down — and it is precisely on them that the report diverges from reality after a year.
Reconciliation belongs in the process, not in Excel
In practice, we see a column where someone writes "ok" or "difference" by hand. That's not a check, that's a habit. The contract agrees that the comparison with the source is blocking control: while it is not sitting, the report is not published and a notification is sent to the data owner.
Open-ended questions are not shameful
The last thing that saves a document from being thrown away: a sheet with open questions. No one fills out a contract completely the first time. A question like „does this include inter-warehouse transfers?“ is not a deficiency — it’s a task for a decision, with a name and a deadline. It’s worse when someone fills it out with an estimate and no one asks anymore.
Where to start
You don't have to do it for the entire data warehouse at once. Take one report that's been bothering you for a long time and write it down. You'll find out two things: how much knowledge is just in people's heads, and how many decisions no one has ever made.
We have prepared a blank data contract template that you can fill out yourself. Write to us and we will send it to you.