Finance Technology Stack: A Reference Architecture for ERP, Planning, Billing, Treasury and Reporting

A finance technology stack becomes difficult to govern when several applications can claim the same number, status or master record. The problem is rarely the number of tools by itself. It is the absence of an agreed answer to three questions: which system may create or change a record, when authority moves to another system, and what evidence proves the handoff completed.

This reference architecture treats ERP, planning, billing, treasury, consolidation, reporting and finance data as distinct layers with explicit boundaries. It is designed for target-state decisions, not product selection or interface design.

Finance technology stack reference architecture at a glance

For this guide, a system of record is the application or external record authorized to create, amend or confirm a governed object at a defined lifecycle status. That definition is narrower than calling one platform the source for all finance data. An invoice, for example, can begin as a calculation in billing, become an open receivable in a subledger, produce a posted journal in the general ledger and later appear as a derived measure in a reporting model. Authority changes by status, while the record lineage remains connected.

The map is a logical model. A single suite may contain several layers, and one specialist platform may perform more than one role. The architecture decision is still made at the object and status level. Product boundaries do not remove the need to state who can write, approve, reconcile and correct each record.

The governing rule: one authoritative owner per object and status

Two systems may hold the same identifier or amount, but they should not both have unrestricted authority over the same object in the same status. The test is not whether data is duplicated. Reporting, planning and operational workflows often require copies. The test is whether a user or automated process can change the governed value in more than one place without a defined precedence rule.

Invoice status illustrates the point. Stripe’s invoicing documentation distinguishes draft, open, paid, void and uncollectible states, with different permitted actions at each stage. A finance architecture should make the same distinction even when another billing platform is used. Billing may own the editable draft and finalization event. The receivables subledger may own the open item and accounting status. Cash management may own matching to a bank statement. The general ledger owns the posted accounting effect. A dashboard can display all four, but it should not become an alternate place to repair any of them.

This status-specific model prevents a common design error: declaring the ERP, data warehouse or planning platform the single authority for every fact. The better rule is one authoritative owner for each governed object at each lifecycle state, with traceable handoffs when authority changes.

The finance systems integration map applies those authority boundaries at interface level, including contracts, retries, monitoring and reconciliation.

How to bound each finance system layer

ERP and accounting: own the books and posted actuals

The accounting layer should own the legal-entity ledger, accounting calendar, chart of accounts, subledger accounting and posted journals. SAP describes its Universal Journal as the book of original entry for Financial Accounting and Controlling transactions. The product-specific implementation will vary, but the architectural boundary is useful: once a transaction is posted as an accounting actual, corrections should follow the ledger’s controlled adjustment or reversal process.

Planning systems, billing systems and analytical models can receive accounting actuals. They should not overwrite them locally and present the altered value as booked actual. When a downstream user finds an error, the exception should return to the accounting owner, be corrected in the authorized layer and then flow forward again.

Planning and performance: own approved plan versions and assumptions

The planning layer should own budgets, forecasts, scenarios, targets, planning assumptions and their approval state. Oracle’s planning documentation separates scenario from version: a scenario identifies a data type such as budget, actual or forecast and its time span, while versions represent outcomes or iterations such as draft and final.

That distinction should appear in the target architecture. FP&A needs authority over forecast methods, scenario assumptions and approved versions. It does not need authority to edit imported ledger actuals. Actuals should arrive with period, entity, account, currency and load-status controls, then remain identifiable as accounting-derived data.

Billing and receivables: separate commercial calculation from accounting

Billing should own pricing inputs, usage or quantity inputs received from operational sources, invoice calculation, tax inputs where applicable, invoice finalization and customer-facing invoice status. The receivables subledger should own the open item, applications, adjustments, credit balances and accounting status after the invoice is accounted.

The boundary matters because billing status and accounting status are related but not identical. Oracle identifies its Receivables to General Ledger Reconciliation Report as the primary tool for reconciling receivables data to the general ledger. That need for reconciliation is evidence that the subledger and ledger perform distinct jobs even when they are modules in one suite.

A controlled handoff should preserve invoice ID, customer or account ID, legal entity, currency, accounting date, line totals, tax and total amount. It should also record rejected items and the owner responsible for resolving them.

Treasury and banking: distinguish internal position from external bank evidence

Treasury or cash-management software should own the internal cash position, account coverage, payment workflow, liquidity classifications and reconciliation status. The bank statement remains the external evidence of bank-side transactions and balances. The ledger remains the authority for the accounting treatment.

Oracle’s cash-management documentation describes reconciliation as selecting bank-statement lines and system transactions to be matched, including one-to-one and grouped matches. The architecture should therefore retain both sides of the match, the rule or user action that linked them, and a queue for unmatched or ambiguous items.

Payment initiation needs the same clarity. One designated system should create or release the instruction for each payment channel. Approvals may originate elsewhere, but the final release right, bank acknowledgement, rejection status and resubmission path must be assigned rather than inferred.

Consolidation and reporting: own the group result, not source transactions

The consolidation layer should own entity hierarchies used for group reporting, currency translation, intercompany eliminations, ownership calculations, consolidation journals and the status of the group result. Oracle defines consolidation as gathering data from descendant entities and aggregating it to parent entities, with translation where child and parent currencies differ.

Local books should remain intact. Group-only eliminations or adjustments belong in the consolidation layer unless accounting policy requires a legal-entity posting. Controlled reporting can then publish statutory and management outputs from the approved consolidation state, with version, period, entity scope and sign-off preserved.

Finance data and analytics: own the analytical representation

A warehouse, lakehouse or semantic model should own historical analytical copies, conformed dimensions, transformation logic and governed metric definitions. Microsoft recommends a data warehouse and extract, transform and load processes for demanding scenarios, with the semantic model connecting to the warehouse. That is an analytical architecture, not permission to repair source transactions in the reporting layer.

Finance data teams should be able to correct mapping logic, dimensional history and metric definitions through controlled changes. They should send transaction or accounting errors back to the authoritative operational or ledger owner. Each published measure should state its source, grain, currency treatment, period logic and reconciliation point.

The cross-cutting control plane: make the boundaries operable

System boundaries have little value unless access, monitoring and evidence support them. The 2025 GAO Green Book, which applies to US federal agencies, emphasizes documented risk assessment, preventive control activities and internal-control responsibility at multiple management levels. It is useful here as a control-design lens, not as a private-sector requirement.

For each layer, the control plane should define write access, approval authority, master-data change rights, interface monitoring, control totals, reconciliation frequency, evidence retention and exception escalation. Technology operations may run the platform, but the finance owner remains accountable for the governed object and its control outcome.

System-of-record, ownership and boundary matrix

The matrix below is a starting model. Replace generic application labels with the actual platform and named owner in the target architecture. Where one suite contains several modules, keep the rows separate so that write rights, statuses and controls remain explicit.

Six boundary tests before approving the target architecture

1. Authority test: Name the one system allowed to create, change, cancel or approve the object at each status. If two systems can perform the same write without precedence, the boundary fails.
2. Lifecycle test: State the event that transfers authority, such as invoice finalization, accounting posting, bank acknowledgement, plan approval or consolidation sign-off. Record the identifiers that connect the before and after states.
3. Posting and reconciliation test: Define the control total, record count, amount, currency, period and acceptance status used to prove the handoff. State how subledger-to-ledger, book-to-bank and source-to-report differences are investigated.
4. Master-data and access test: Assign who may change entity, account, customer, supplier, bank-account and reporting dimensions. Confirm that downstream copies cannot bypass the approved change route.
5. Grain and timing test: Specify transaction grain, aggregation, effective date, accounting date, as-of time and refresh expectation. A real-time dashboard built on daily accounting extracts is still daily for that measure.
6. Exception and evidence test: Name the owner, queue, service expectation, escalation and retained evidence for rejected, missing, duplicate, late or ambiguous records. An automated handoff without an owned exception path is incomplete.

Suite versus specialist systems is a boundary decision

A suite can reduce the number of handoffs and place ledger, subledger, master data and reporting controls under one administration model. That is valuable when shared accounting dimensions, legal-entity consistency and close control matter more than specialized process depth.

A specialist system can be justified when billing logic, treasury connectivity, planning methods, transaction volume or user workflow exceeds what the suite can support. The specialist should not be approved on functional depth alone. It also needs stable identifiers, explicit write rights, complete status returns, reconciliation evidence, security ownership and an exit path for failed transfers. For AI-supported bank workflows, the Moody’s AI systemic dependency warning adds a second boundary test: prove that model and cloud dependencies are mapped, substitutable and covered by a funded exit plan.

Turn the reference architecture into an operating register

1. Inventory governed objects and statuses. Begin with the objects that affect financial statements, cash, plans and management reporting. Avoid starting with a product list.
2. Assign the authoritative application and accountable owner. Record the system, finance owner, technology owner, legal entity or business scope and allowed write actions.
3. Document every transfer of authority. Capture the triggering event, identifiers, timing, grain, control totals, acknowledgement and required reconciliation.
4. Attach the exception operating model. Name the queue, resolver, escalation, ageing rule and evidence retained for each failed or disputed handoff.
5. Govern architecture changes as control changes. Reassess the register when a new application, entity, bank, billing model, reporting requirement or data transformation changes an authoritative record or handoff.

The completed register should be usable by finance, technology, data and control owners in the same review. It should show not only where data resides, but who may change it, what event moves it, how the transfer is proven and where an exception is resolved.