A finance data model is the agreed structure behind each finance record: the entity and counterparty it belongs to, what each amount means, the period it covers and the evidence that supports it. With one in place, a close reviewer reuses what AP already established about a balance and skips the second investigation.
Without one, the work repeats. An AP accountant spends a day on a supplier balance. They find the credit note, tie it to the right supplier account and show that part of the credit was already applied. At close, another accountant needs to explain the same balance. The number sits in the ERP. The explanation sits in a spreadsheet, an email thread and the first accountant’s memory, so the close team starts again.
That rebuilt explanation is the case for a canonical finance data model: a connected record that keeps the relationships, meaning and evidence from the first investigation so the next workflow can use them.
Follow one credit from AP into close
Take a supplier credit of $20,000 in USD within one legal entity, an illustrative figure for this series. AP finds allocation records showing that $14,000 was applied earlier. The remaining $6,000 needs further checks before anyone can say whether it is still available.
AP’s explanation now holds several facts: the original credit, the prior application, the supplier and entity identities, and the records behind the calculation. It also holds a limitation, because the remainder is still under investigation.
The close reviewer needs that explanation to assess the supplier balance. They should open the same allocation records, follow the calculation and see what remains open. Their accounting review is a separate job, but confirming the prior application should not take a second search.
Use that handoff as the test of your foundation, and record whether the close reviewer reused AP’s work or rebuilt it.
What a finance data model has to carry
A finance data model keeps four agreements with the number.
Identity: the supplier account and legal entity the credit belongs to. Keep the original source identifiers and the basis for any mapping. A similar supplier name does not prove that two entities share one obligation.
Meaning: what each amount represents. Here $20,000 is the original credit, $14,000 a prior application and $6,000 a possible remainder. A field labelled “credit amount” leaves the next person to guess which one they received.
Time: the events included and the cutoff they run through. An allocation imported today can describe an event from an earlier period, so the close reviewer needs the event history for their review as well as the extraction date. Checking the history behind a finance answer shows how to test that coverage.
Evidence: the records that support the explanation, and whether the intended reviewer can open them. Keep the credit, the application and the supporting documents connected to the result, and carry the missing-evidence note forward.
A final amount copied into another spreadsheet carries none of the four, and the close team opens the investigation again.
Find where your existing process loses the explanation
Start with a completed investigation and follow its next handoff. Ask the receiving reviewer to locate the support and reproduce the calculation with their own access.
Note the point where they need the original preparer’s help. In one team the reviewed supplier mapping lives in a local file. In another the attachment lacks the period or entity, or links to a document the reviewer cannot open. Each is a specific gap with an owner to fix it.
Check what your existing systems already do. The ERP keeps approved postings, a document store keeps evidence, and a data platform maintains relationships and definitions. Find who maintains each responsibility before you decide what to add. The comparison of a finance data warehouse, a canonical model and a semantic layer sorts those responsibilities.
Keep the real differences between workflows visible. AP prepares a supplier question while the close reviewer assesses accounting treatment. Both use the same evidence, and each keeps its own judgment and approval.
Test reuse before expanding the workflow
Choose one balance, one investigation and one downstream review. Agree the population and cutoff, then keep the explanation in a form the next reviewer can inspect.
If new evidence changes the answer, keep the earlier version and record why it changed. Identify the downstream review that used it. A maintained foundation has to update dependent work as well as share the first result.
The first proof is concrete: a second workflow uses the reviewed relationships and evidence without reconstructing them. Rever starts from the same idea. Eve builds your business context and your mappings are approved before the zero-day scan checks the connected records; the Explore Rever page on Mapping Studio and the canonical data model explains that step.
The One Balance, Two Workflows worksheet runs that handoff with your team. It includes the worked credit example and a blank review sheet.
To run the same check on screen, Can the Explanation Travel? takes one balance and two workflows, checks the identity, meaning, time and evidence that travel between them and prints a handoff summary with the gaps and their owners.
