Finance Data Management: Ownership, Quality, Lineage and Access Controls

Most finance teams can name the system that holds a number. Far fewer can name the person who decides what that number means, the document that records the decision, or the evidence that would satisfy an auditor asking how the figure was assembled. A ledger balance, a headcount, a renewal date and a vendor bank account all sit in applications that someone administers. None of them has an owner until a named person is accountable for the rule that produced it.

Finance data management is the work that closes that gap. It is not a platform purchase and it is not the same as choosing a warehouse. It is twelve governed decisions about meaning, accountability, movement and proof, of which ownership, quality, lineage and access are the four that fail most visibly. This page sets out each one as work a named role does, the artifact that records it, and the test that shows it is holding.

What finance data management covers, and what it is often confused with

Finance data management is the set of decisions that keep the finance function’s own data usable: what each measure means, who is accountable for it, how it is created and changed, how it moves, and what proves it is fit to report. The governed objects are specific: the chart of accounts, the dimensions attached to it, entity and counterparty master data, rate and tax reference data, metric definitions, mappings, and the reports built on all of it.

Two other subjects share the phrase and are not this. The first is data management inside a financial institution, where customer, market and risk data are the product. Banks work to a separate regime: the Basel Committee published Principles for effective risk data aggregation and risk reporting on 9 January 2013, addressed to global systemically important banks. That is a supervisory obligation with its own scope and is not what a corporate controller is being asked to build.

The second is enterprise data governance in general. The vocabulary overlaps, but the objects do not. A general framework will tell you to appoint owners and stewards. It will not tell you who approves a new account, how a dimension value is retired, or what an auditor accepts as evidence that a reported figure was complete.

The governing rule: a system of record is not a data owner

The single distinction that makes this work tractable is between the application authorized to hold a record and the person accountable for what the record means. Deciding which system may create or change each finance object is an architecture question, and it is settled separately. It does not answer who signs off that the revenue definition used in the board pack matches the one used in the sales compensation plan.

A system cannot approve a definition. It cannot decide that a cost centre should be retired at period end rather than immediately, accept a reconciliation with an unexplained residual, or judge that a mapping change is material enough to need a controller’s approval. Those are judgements, and every one of them has to belong to a person whose name is written down.

The twelve finance data domains at a glance

Each domain below produces one artifact. The artifact is the point: it is what makes the decision reviewable, transferable when someone leaves, and available when an auditor asks. A domain with no artifact is an intention.

Define what the numbers mean

Meaning is the layer that fails first and is repaired last, because a definition disagreement produces two defensible numbers rather than an obvious error.

Business definitions and the finance metric dictionary

A metric dictionary records, for every measure that reaches a board pack or an external report, the plain-language definition, the calculation, the source of each input, the period and currency treatment, and the person who approves changes to it. The test is simple: two analysts working independently from the dictionary should produce the same number.

The cost of skipping this is not usually an error. It is two correct answers to different questions presented as one. Cisco reported $9.3 billion of fiscal 2026 AI-infrastructure orders and approximately $4 billion of AI-infrastructure revenue for the same period, and orders and revenue are two different measures of the same commercial activity. Without a dictionary entry naming which measure a slide is using, the comparison a reader makes is the wrong one.

Chart of accounts and dimension governance

The chart of accounts is a controlled vocabulary, and it degrades when account creation is treated as a service request. Governing it means a written request and approval route, a stated use rule for each account, a versioned hierarchy, and a retirement process that closes an account to posting rather than deleting a code that history depends on. Where the ledger layer itself is under review, how controllers evaluate the ledger layer is a separate decision from how the chart on top of it is governed.

Dimensions need the same discipline and rarely get it. Microsoft’s Dynamics 365 Finance documentation, updated 26 May 2026, describes financial dimension values becoming segments within the ledger account, and provides legal entity overrides that record which companies a value is suspended for, its owner, and the period it is active. That is the shape the governance record should take whatever the platform: a value, an owner, a scope and an effective period.

Master data and its authoritative references

Finance master data is distinctive because much of it has an external authority to check against. Using that authority converts a maintenance task into a control with an evidence trail.

Two of these deserve emphasis. The IRS states that TIN Matching lets a payer validate TIN and name combinations before submitting an information return, which moves a correction out of filing season and into vendor onboarding. And vendor bank detail changes are an attack surface, not paperwork: the FBI Internet Crime Complaint Center recorded 24,768 business email compromise complaints and $3,046,598,558 in reported losses during 2025.

Assign accountability with a RACI, not a committee

A data governance committee that meets monthly is not accountability. Accountability is one named person per decision, recorded where the decision is made.

Owner, steward and custodian are three different jobs

The owner decides. That is a finance leader who approves the definition, the account, the threshold or the exception, and who carries the consequence if the number is wrong. The steward maintains. That is the person who creates and corrects records inside the agreed rules and escalates what the rules do not cover. The custodian operates the platform, applies access, runs the jobs and keeps the backups. Collapsing the three is the most common failure, and it usually collapses upward into IT, where the accountable person has no basis to approve an accounting judgement.

Write it as a RACI covering all twelve domains, with the owner named as accountable in exactly one place per domain. If two names appear against one decision, the decision has no owner.

Access and segregation of duties

Finance access design answers three questions: who may post, who may approve, and who may change the rules that decide what posting is allowed. Those must not be the same person for the same transaction class. Beyond posting rights, some finance data is restricted by content rather than by function, including payroll, provisions, impairment work and transaction files, and that restriction has to survive extracts into spreadsheets and reporting tools.

The evidence auditors ask for is not the role design. It is the periodic review: a dated record showing who held which role, who reviewed it, what was removed, and when the removal took effect.

Change control for accounts, hierarchies, mappings and report logic

Four things change quietly and move reported numbers: account and dimension values, hierarchy structures, mapping tables, and the calculation logic inside reports. Each needs a change record naming the requester, the approver, the date, the reason and the periods affected, and a freeze window during close when only the controller may approve a change.

The failure mode is a change that happens correctly somewhere and never reaches the place it matters. Pelthos Therapeutics filed a first-quarter Form 10-Q/A on 13 August 2026 after concluding the original statements should not be relied upon, because subordination agreement terms agreed in January were not reflected in the valuation of Level 3 convertible debt. It is a contract change that never reached the valuation input, which is a change control gap rather than a calculation error.

Prove the data moved and can be traced

Movement and traceability are separate problems. One is about what crosses a boundary; the other is about reconstructing a number after the fact.

Integration data contracts

The design of an interface is its own discipline, and interface patterns, retries and transfer states are settled there. What belongs here is narrower: the data contract. For each interface, record which fields cross, which system owns each field’s values, what makes a record valid, what the receiving side does with an invalid record, and who is accountable when the contract is broken. That accountable person is the business data owner, not the interface owner, because the question is whether the data means what the receiving process assumes.

Where the source is a third party, the control does not disappear. The AICPA describes a SOC 1 report as an examination of controls at a service organization that are likely to be relevant to user entities’ internal control over financial reporting. Reading it, and testing the complementary controls it assumes you operate, is a finance task.

Lineage from source transaction to reported line

Finance lineage is narrower and more demanding than technical column mapping. The question is whether a person can start at a reported line and reach the source transactions that produced it, naming every transformation on the way: subledger to control account, control account to ledger, ledger to consolidation adjustment, consolidation to report line, report line to disclosure. Each hop should identify what changed the value and who authorized that change.

Test it by picking one line from the last board pack and walking it backwards. If the trace needs a specific analyst to be available, the lineage is held in someone’s memory, not in the record.

Prove the data is fit to report

Fitness is demonstrated, not asserted. Three mechanisms do it, and they answer different questions.

Data quality rules finance can enforce

Useful finance data quality rules are specific and few. Each names the object, the condition, the threshold, the owner and the repair route: no posting to a retired account; every vendor with a payment in the period holds a validated TIN; every intercompany balance has a counterparty entity populated; no journal above a stated value without a supporting reference. A rule without a named repair owner produces a dashboard nobody acts on. The same discipline applies outside the ledger, where spend data requirements and classification blind spots determine whether a category analysis can be trusted at all.

Reconciliation as the completeness test

Reconciliation is the control that answers whether the population is complete, which no quality rule can do on its own. A quality rule inspects the records present; a reconciliation asks whether records are missing. Treat subledger-to-ledger, bank, intercompany and third-party agreement as the completeness evidence for the data behind each reported balance. The mechanics of preparation, review and exception handling sit with reconciliation ownership, evidence and exception handling.

Coles Group’s FY26 results, released 25 August 2026, reported net profit after tax of A$1.255 billion excluding significant items and A$1.090 billion including them, a A$165 million after-tax difference driven by a A$235 million pre-tax charge linked to Fair Work Ombudsman proceedings. It is an underpayment charge that moved a reported result, and the underlying exposure is employee and rate data applied over time.

Control evidence and information produced by the entity

When a report supports a control, the report itself becomes something an auditor tests. PCAOB AS 1105 requires an auditor using information produced by the company as audit evidence to test the accuracy and completeness of the information, or test the controls over the accuracy and completeness of that information. Staff Audit Practice Alert No. 11, issued 24 October 2013, puts the same point in operating terms: where a control uses system-generated data or reports, the effectiveness of the control depends in part on the controls over the accuracy and completeness of that data.

In practice that means retaining, for each report used in a control, the parameters and filters used, evidence of the population it covered, the version of the logic that produced it, and the reviewer’s record of what was checked. This is the same evidence discipline that what an automated close step has to leave behind applies to automation, extended to every report a control depends on. The wider frame is long established: COSO states that its Internal Control framework, issued in 1992 and refreshed in 2013, was developed as guidance to help improve confidence in all types of data and information.

Reporting: one definition, one source, one certified version

Reporting is where every earlier decision becomes visible. Three rules keep it governable. Certified reports draw their definitions from the metric dictionary rather than restating them locally. Each certified report names one source for each figure, so a number never has two competing production routes. And the report inventory distinguishes certified outputs, which carry an owner and a review, from analysis, which does not and should not be presented as though it does. For board-facing outputs, the separate guide to board reporting software distinguishes the system that produces the numbers from the tools that assemble and distribute the pack.

Spreadsheets are not the enemy, but an uncontrolled spreadsheet between a system and a reported number is an undocumented transformation. Where one exists, it needs the same owner, version and review as any other step. Machine-readable output raises the bar again: FASB publishes an annual GAAP Financial Reporting Taxonomy, with the 2026 release posted in December 2025, and a tagged figure has to match the visible statement it came from.

The exception path: what happens when a rule breaks

Every domain above will fail at some point. What separates a governed environment from a documented one is whether the failure has a route. Define, once, for each domain: what triggers an exception, who is notified, who may approve a temporary workaround, how long a workaround may stand, and what closes it.

Three rules make the path work. An exception is assigned to a person, never to a team inbox, because a queue with no name ages indefinitely. Every workaround carries an expiry date at the point it is approved, so continuing it becomes a decision rather than a default. And an exception that recurs is reclassified as a design problem after a stated number of occurrences, which is what stops a manual repair becoming permanent unwritten process.

The evidence an exception path produces is also the evidence a reviewer needs: what broke, when, who decided, what the interim treatment was, and when it ended.

A worked example: tracing one reported number end to end

Take a single line on a management pack, revenue for one business unit for one month, and walk it against the framework. This is a trace structure rather than a case study, and the figures below are illustrative.

Start at the reported line. The metric dictionary should state whether it is invoiced revenue, recognized revenue or an order measure, and name the approver of that definition. Move back to the report: which certified report produced it, from which single source, and under which version of the calculation logic. Move back to the ledger: which accounts and which dimension values make up the business unit, and whether any of those dimension values changed scope during the period. Move back to the subledger: does the subledger agree to the control account, and is the residual explained and aged. Move back to the source: did every transaction in the population cross the interface, and does the data contract confirm the fields arrived with the meaning the receiving process assumed.

At each hop, ask what evidence exists if someone disputes the number. A trace that produces a document at every hop is a governed number. A trace that produces a document at four hops out of five has one uncontrolled transformation, and that is where the next restatement risk sits.

Ownership, control test and evidence matrix

Grouped by the question each set of domains answers, this is the summary to put into an operating register.

Sequence the work: what to fix before anything else

Attempting all twelve domains at once is how these programmes stall. The order below reflects dependency rather than difficulty.

Start with definitions for the measures that already reach an external or board audience, because every later control needs something agreed to enforce. Then name owners, stewards and custodians across all twelve domains, even where the underlying process is still weak, so the next decisions have an addressee. Third, put change control around accounts, dimensions and mapping tables, since uncontrolled change will undo any repair made before it. Fourth, fix master data verification at the point of creation rather than by remediation projects. Only then build quality rules and their thresholds, because a rule needs an owner and a repair route to be worth writing. Reconciliation coverage and control evidence come last in build order and first in audit order, which is precisely why they should be designed against the earlier artifacts rather than bolted on.

What this framework does not settle

This is a governance model for the finance function’s own data. It does not choose a data platform, and warehouse or lakehouse selection is a separate decision with different evaluation criteria. It does not design interfaces, and it does not allocate systems of record across the application estate.

It also assumes a corporate finance function rather than a regulated financial institution. A bank subject to BCBS 239 carries specific supervisory expectations on risk data aggregation that are additional to everything here, not a subset of it. Sector rules in insurance, utilities and public bodies impose further requirements that this page does not cover.

One practical limit is worth stating plainly. The evidence standard that matters is the one your auditor applies, and it should be agreed with them before the close in which you intend to rely on it rather than after.

This article is current through 26 August 2026. Claims about audit evidence, internal control and reporting taxonomies are taken from the standard-setter or regulator that issued the material rather than from a summary of it. Product behaviour is cited from the vendor’s own dated documentation and describes that product only. The twelve-domain model itself is Finance Circuit’s operating framework rather than a published standard, and it should be rechecked when the PCAOB, COSO or FASB material it rests on changes.