Building a Semantic Layer
for Financial Close
Structuring accounting data for LLM reasoning and agentic workflows.
TL;DR
Abstract
Large Language Models can perform many types of analysis and automation remarkably well — but only under the right structural conditions. LLMs struggle to infer relationships and semantics from normalized tables that lack contextual cues or domain-specific definitions. Databases often present non-linguistic symbol structures: arbitrary labels, cryptic encodings, and implicit relationships. Current solutions attempt to generalize LLM-to-SQL translation but overlook the semantic abstraction needed to bridge these two paradigms. This paper proposes a semantic specification framework for codifying monthly financial reporting into a machine-interpretable format — a semantic bridge that allows LLMs and agent-based systems to more accurately interpret, query, and execute operations on complex financial data and workflows.
The close process and management reporting are linked — but serve different objectives
The monthly close process focuses on financial accuracy and control: ensuring transactions are posted, reconciled, and verified. Management reporting uses those outputs to serve a separate set of objectives:
- Comparing actuals to expectations and monitoring performance against targets
- Analyzing variances and tracking cash flow
- Supporting audit and compliance readiness, particularly for public or regulated firms
Management reporting draws on the verified outputs of the close to produce distributable materials — income statements, balance sheets, cash flow statements, and internal management reports. Critically, all these outputs have historically been designed for humans to read, interpret, and act on.
What if management reporting also produced deliverables designed specifically for machines — agentic systems capable of reading, reasoning over, and eventually acting on structured financial data?The case for a machine-readable financial document
Today, the outputs of financial reporting are delivered in PDFs, spreadsheets, and slide decks — with business logic and context embedded implicitly in spreadsheet formulas, narrative prose, and institutional knowledge. Machines struggle to interpret or act on these insights consistently without extensive prompt engineering or brittle one-off transformations.
When a financial analyst looks at a single line item in an Excel workbook or PowerPoint slide, they are not just seeing a number. They are interpreting it through layers of preexisting knowledge: the business drivers, expected seasonality, operational activity, and prior period benchmarks. This context is second nature to humans.
To an LLM or autonomous agent, that same number is just an arbitrary key-value pair buried in a file — with no semantic signal to indicate what it means, where it came from, or why it matters.
Semantic specification layer — a worked example
Rather than treating values as isolated numbers in a spreadsheet, the document organizes them into well-defined objects enriched with metadata, business logic, and contextual meaning. Consider the Income Statement for the month ending June 2025, focusing on "Total Service & Other Revenues."
| # | Line Item | 6/25 |
|---|---|---|
| 1 | Advisory Fees | 10 |
| 2 | Maintenance Revenue | 5 |
| 3 | Miscellaneous Income | 2 |
| 4 | Technical Service Fees | 3 |
| 5 | Training Income | 1 |
| 6 | Total Service & Other Revenue | 21 |
A semantic definition for "Total Service & Other Revenue" encodes the meaning, not just the value:
The second object pairs actuals with referential connections to the definition:
When these two objects are provided to a model, the results are meaningful:
Advisory Fees: $29.2M · Maintenance: $14.7M · Technical Fees: $8.7M · Misc. Income: $5.7M · Training: $2.85M
Revenue grew steadily month-over-month — May increased 2.78% over April; June increased 3.19% over May. Advisory Fees dominated the mix (~48%). The steady growth across all components suggests broad-based expansion rather than one-off events.
If it works, these systems would understand workflows — not just automate them
If a financial semantic layer can meaningfully improve LLM accuracy and reliability on financial data, LLMs could augment traditional tools for financial modeling, simulation, and scenario generation. These systems would not merely automate existing workflows — they would understand them, reason over them, and adapt continuously with minimal human intervention.
By embedding financial meaning directly into data structures, agents could:
- Roll up and unwind intercompany entity activities
- Perform real-time modeling, simulation, and forecasting based on semantically linked actuals
- Suggest automated refinements to classifications, accruals, or estimates during the close process
- Propose and post journal entries in response to business events or policy conditions
- Maintain explainability and auditability at every step, with clear lineage to underlying logic
Where existing solutions fall short
Most efforts to incorporate AI into financial workflows have focused on translating natural language into SQL (OpenAI Codex, Microsoft Copilot). These approaches operate syntactically — treating tables as flat and context-free.
Tools like dbt offer semantic modeling, but are typically used for transformation logic in the ELT pipeline — not for encoding financial meaning. Looker's LookML and Microsoft Fabric semantic models bring structure to BI reporting, but lack the financial domain specificity and agent-oriented design needed for reasoning and autonomous action.
ERP systems such as SAP and Oracle maintain chart-of-accounts metadata and can provide structured reporting outputs, but these are rarely agent-accessible in practice. Workiva and Anaplan offer connected reporting capabilities, but the semantics are implicitly tied to spreadsheet formulas and hardcoded logic.
To our knowledge, no solution yet formalizes monthly close outputs in a modular, reusable, and machine-interpretable format designed explicitly for LLM consumption. This work aims to fill that gap.For real-world viability: auditable, versioned, and governed
Each definition should carry metadata establishing provenance and control:
- version — A monotonically increasing integer or semantic version string
- created_by / approved_by — Establish provenance and control
- effective_period — Restrict use to specific time windows (e.g., fiscal Q2)
- change_log — A structured array of amendments, timestamps, and reasons
Governance frameworks could follow patterns similar to data contracts, with specification authorship owned by the finance team but validated by data engineering or controls groups. Automated diffing tools should detect semantic drifts across periods, flagging when business logic changes may affect downstream analytics or agentic behavior.
While this paper focused on a single revenue line item, the approach is extendable to: balance sheet metrics, cash flow classifications, variance analysis and explanations, and narrative management reporting.
Models tested
Terms used in this framework
"account": "COGS".