The New Finance Data Layer: API, Export, Inbox, PDF, Reconciliation

Stop Looking For One Perfect System

The modern service business rarely runs on one system.

It has:

field software
accounting software
payroll
bank feeds
customer portals
emailed reports
invoice PDFs
spreadsheets
dashboards
human review

The owner wants one answer.

The systems produce many partial answers.

That is the gap.

The Level view:

The new finance data layer is not a replacement system. It is a reconciled layer across APIs, exports, inboxes, PDFs, accounting, and weekly owner decisions.

Source and claim note: Public developer docs from QuickBooks Online, Xero, Jobber, ServiceTitan, and NetSuite support the general idea that business systems expose integration surfaces. Level's architecture below is a service-delivery framework, not a claim that every vendor exposes every field or that one automation replaces finance judgment.

The Five Inputs

API

Use APIs where they are reliable.

They are often best for structured records, refreshable data, and repeatable pulls.

But the API is one witness.

It is not always the complete operating truth.

Export

Exports are underrated.

The trusted report may already include the filters, statuses, and business definitions the team uses.

If the report can be scheduled or controlled, it may be the fastest path to usable finance data.

Inbox

An inbox can become a data intake layer when it has controls.

Known sender.

Expected subject.

Expected file.

Expected columns.

Validation.

Exception handling.

Read the AI inbox playbook for the detailed version.

PDF

PDFs and documents hold proof.

Invoice backup, signed tickets, customer portal confirmations, retainage notes, and purchase orders can explain whether AR turns into cash.

The PDF is evidence, not the ledger.

Reconciliation

This is the layer most teams skip.

The business has to decide which source wins when systems disagree.

That decision cannot be outsourced to a pretty dashboard.

The Owner Questions

The data layer exists to answer owner questions:

will we have enough cash in each of the next 13 weeks?
which work is complete but not billed?
which invoices are stuck because proof is missing?
which customers are underpriced?
which jobs lost margin after payroll landed?
which branch or crew changed profitability?
which WIP number should we trust?
which exceptions need action this week?

If the data layer does not answer these, it is just plumbing.

Useful plumbing, but still plumbing.

For the cash version, read the 13-week cash forecast is a data-layer test.

Free benchmark review

See whether your books are benchmark-ready.

We check whether your financial data is clean enough to trust, then show the fastest path to a useful benchmark.

The Wrong Architecture

The wrong architecture is vendor worship.

"Once the integration is live, finance will be fixed."

That is rarely true.

The wrong architecture also includes:

API-only automation
dashboards before reconciliation
AI summaries over untrusted numbers
manual exports with no validation
PDF extraction with no tie-out
no owner for mapping changes
no weekly exception review

The system can be modern and still fail the owner.

The Right Architecture

Start with the decision.

Then map the sources.

Then define the reconciliation rules.

Then build the intake.

Then review exceptions.

The sequence matters.

For each owner question, define:

source system
source owner
object IDs
dimensions
refresh timing
document evidence
validation checks
exception thresholds
action owner
review cadence

This turns data into operating finance.

What AI Changes

AI changes the economics of messy data work.

It can read documents.

It can compare fields.

It can classify exceptions.

It can draft summaries.

It can help with browser workflows when the business owns the workflow.

But AI does not remove the need for finance design.

The company still needs source ownership, review cadence, and judgment.

That is why Level stays services-first.

The tools are better.

The work is still making the numbers usable.

The Minimum Viable Data Layer

The first version can be small.

It does not need to cover every system.

It needs to cover one owner decision end to end.

For a cash decision, that may mean:

bank balance
AR aging
invoice proof status
billing queue
AP timing
payroll calendar
13-week forecast

For a margin decision, that may mean:

field job
accounting invoice
payroll cost
material cost
customer/site mapping
class or location
close adjustment

For a customer decision, that may mean:

contract or service agreement
hours worked
invoice value
callbacks
payment timing
price increase history

The test is whether the owner can make a better decision next week.

If yes, expand.

If no, do not add more data yet.

Fix the source, mapping, or review cadence first.

This is why a data-layer audit should precede any major dashboard or AI project, and why benchmarking is most useful after the company can trust its own baseline.

What Level Builds

Level helps service businesses build the layer around the systems they already run.

That may include:

field-system API pulls
accounting API pulls
scheduled Excel exports
AI inbox ingestion
invoice PDF extraction
approved browser workflows
reconciliation tables
weekly exception lists
cash forecasts
CFO interpretation

The outcome is not a software demo.

The outcome is an owner saying:

I know which number changed, why it changed, and what we are doing about it.

See whether your books are benchmark-ready.

Want next week's benchmark in your inbox?

See whether your books are benchmark-ready.