A finance data warehouse is a central store that brings together records from the ERP, banks and other finance systems, keeps their history and makes them available for reporting and analysis. It holds the records. The supplier mappings, measure definitions and explanations a reviewer relies on need a home of their own: a canonical model and a semantic layer.
A Controller asks why AP and the close team still explain the same supplier balance twice. The systems team points to the warehouse, where both workflows already have the data. Both are right. The records sit in one place while the supplier mapping, the meaning of each amount and the explanation stay local to each workflow.
Separate three responsibilities: storing records, representing their relationships and defining the measures people use. A finance data warehouse, a canonical model and a semantic layer handle them in different ways, and one implementation can cover all three.
What a finance data warehouse does, and where it stops
Your team keeps history in the warehouse and organises access to the extracts from the ERP, banks and other sources.
The warehouse alone does not show that a statement account and an ERP vendor reference represent the same supplier in the same legal entity. A payment table does not say which application explains a particular credit.
Your transformation models might already hold those relationships. If they do, find where they are maintained and which consumers use them. The gap to investigate is the accounting interpretation people still rebuild outside that maintained process.
Ask the next reviewer to reproduce one explanation from the records. Their difficulty tells you more about the missing responsibility than the architecture label does.
A canonical model gives different records a common representation
A canonical model sets a shared representation that each participating application maps to. It is an established integration pattern: Canonical Data Model, Enterprise Integration Patterns. In finance, the work covers agreed supplier and entity identities, transaction relationships and source references. The Explore Rever page on Mapping Studio and the canonical data model covers Rever’s version: your source records mapped to one canonical record, with the mappings approved before the zero-day scan checks the connected records.
Take the illustrative credit used across this series. Credit CN-410 has an original value of $20,000. Verified applications show $14,000 used earlier. The $6,000 that may remain needs further checks.
The shared model has to keep which supplier and entity own the credit, which allocation records explain the application, which dates control the review and where the evidence sits.
An unresolved mapping stays unresolved. Similar names or equal amounts do not establish a relationship. The model makes the reviewed interpretation available and keeps the source identities someone else needs to challenge it.
A semantic layer gives measures explicit definitions
A semantic layer publishes shared metric definitions to the tools that consume them. dbt, for example, describes defining metrics over existing models and exposing them through supported integrations: dbt Semantic Layer. Each finance application still has to be connected before it reads those definitions.
In finance, “supplier spend” could mean committed orders, invoiced purchases, recognised expense or cash paid. Your team needs each of those measures for a different purpose.
Define the population, event date, calculation and filters for the measure you choose. Then confirm that the report or agent uses that definition. A dashboard with a copied calculation drifts from a consumer that uses the maintained one as soon as either changes.
For CN-410, the original credit, prior application and possible remainder keep separate labels. A common field called “credit amount” leaves the next workflow to guess which measure it received.
Compare responsibilities using one finance question
Use a concrete question: what supports this supplier balance at the close cutoff?
| Responsibility | What to inspect |
|---|---|
| Storage and history | The retained source records, covered period and extraction version |
| Identity and relationships | The reviewed supplier/entity mapping and credit-to-application links |
| Measure definition | Which amount is being reported, with its calculation and date basis |
| Evidence and access | Whether the receiving reviewer can inspect the support |
| Maintenance | Who updates the mapping or definition, and which consumers are affected |
Your existing systems hold some of these responsibilities already. The review locates them and names the missing work.
An architecture diagram earns its place when the Controller uses it to name an owner and trace an answer. If yours names only technologies, add the definitions and handoffs your finance team relies on.
Test the second use of the explanation
AP uses the credit history to prepare its next supplier question. The close reviewer uses the same application evidence to assess the balance. Their outputs and accounting judgments stay distinct.
Ask the close reviewer to inspect the original identifiers, reproduce the $14,000 application and see the open condition on the $6,000 remainder through their own access. Record any mapping or explanation they still need the AP preparer to rebuild. Before you treat the warehouse records as complete, check the history behind the finance answer.
Then change one input in a controlled example and see whether the team can name the explanation and downstream review that need revision. Shared definitions create shared dependencies, so ownership and retained versions matter alongside the first reuse. Build or buy finance data integration applies the same test to an investment decision.
The One Balance, Two Workflows worksheet turns this test into a review of what the next person can use.
For one balance on screen, Can the Explanation Travel? checks whether its explanation travels between two workflows and prints a handoff summary with the gaps, the owners and who reviews it next.
