What a Data-Layer Audit Should Actually Check

The Audit Is Not A Software Demo

A data-layer audit should not start with a vendor pitch.

It should start with the owner.

What number do you not trust?

What decision is harder because you do not trust it?

Cash?

Margin?

AR?

Billing speed?

WIP?

Customer profitability?

Labor cost?

That answer determines the audit.

The Level view:

A useful data-layer audit maps source systems, source owners, IDs, dimensions, refresh timing, documents, reports, exceptions, and decisions before promising automation.

Source and claim note: This checklist is Level's service framework. Public developer docs from QuickBooks Online, Xero, Jobber, and NetSuite support that many systems expose integration surfaces, but the audit itself is about finance readiness, not raw API coverage.

1. Owner Decision

Start with the decision.

Examples:

• can we make payroll and pay vendors over the next 13 weeks?
• which customers should be repriced?
• which jobs are losing margin?
• which completed work is not billed?
• which AR is collectible?
• which branch or crew should grow?
• which project has WIP exposure?

If the audit does not tie to a decision, it will become a data inventory.

Data inventories are useful.

They do not create urgency.

2. Source Systems

List every source involved in the decision.

Common systems:

• field software
• accounting ledger
• payroll provider
• bank
• customer portal
• project management system
• AR automation tool
• emailed reports
• PDFs and backup folders
• spreadsheets

Do not judge the stack yet.

Map it first.

3. Source Owners

Every important source needs an owner.

Who owns the field system?

Who owns accounting?

Who owns payroll?

Who owns customer portal exports?

Who owns invoice backup?

Who owns mapping changes?

No owner means no control.

No control means the number will drift.

4. IDs And Dimensions

This is where many finance projects fail.

Map:

• customer ID
• site or property ID
• job or project ID
• invoice number
• service agreement
• class
• location
• cost code
• item
• technician or crew
• branch
• vendor

Then ask which dimensions survive the sync.

The transaction can move while the dimension that matters disappears.

5. Refresh Timing

Ask when each source updates.

Daily?

Weekly?

After close?

After payroll?

After the report export?

After a human clicks submit?

Timing differences create fake margin and fake cash confidence.

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

6. Documents And Proof

Map the documents that prove the number.

For AR:

• invoice PDF
• signed ticket
• purchase order
• backup package
• portal confirmation
• dispute note

For job margin:

• labor detail
• material invoices
• change orders
• field notes
• close review

Documents should not replace the ledger.

They should support review.

Read from invoice PDF to cash forecast for the document version.

7. Reports And Exports

Find the reports people already trust.

They may be ugly.

They may be Excel.

They may be emailed.

They may be the most useful source in the company.

The audit should ask:

• who runs the report?
• what filters are used?
• what columns are expected?
• how often does it run?
• who notices if it changes?
• can it be scheduled?
• can it be loaded into a controlled pipeline?

Do not mock the export.

Understand why people trust it.

8. Reconciliation Rules

When systems disagree, which source wins?

That is the core question.

Define rules for:

• customer mismatches
• job mismatches
• invoice amount mismatches
• date differences
• missing documents
• duplicate records
• late payroll cost
• AR status conflicts
• WIP status conflicts

Without rules, the data layer becomes a debate.

Read the reconciliation layer is the moat.

9. Exception List

The audit should end with exceptions, not a vague roadmap.

For each target number, produce:

• exception type
• source systems involved
• dollar impact
• owner
• next action
• due date

This creates an operating cadence.

Read the weekly exception list.

10. Automation Readiness

Only after the above should the audit recommend automation.

Possible automations:

• API pulls
• scheduled exports
• AI inbox ingestion
• invoice PDF extraction
• approved browser workflows
• reconciliation tables
• exception alerts
• weekly owner summaries

The question is not "Can AI do this?"

The question is:

Can we validate the source, reconcile the output, and route exceptions to a human?

If yes, automate.

If no, fix the process first.

What The Audit Should Produce

The output should be concrete.

A useful data-layer audit should produce:

• the owner decision being improved
• the number the owner trusts least
• the systems involved
• the source owners
• the key IDs and dimensions
• the refresh schedule
• the missing documents or reports
• the reconciliation rules
• the top exceptions
• the first 30-day fix
• the automation candidates
• the risks that still need human review

That deliverable is more useful than a generic system diagram.

It tells the owner where trust breaks.

It tells finance what to fix.

It tells operations which source systems need cleaner discipline.

It tells AI what work is safe to automate.

And it prevents the company from buying another dashboard before the underlying number is ready.

For companies with obvious cash pain, pair the audit with the cash-gap calculator so the first project connects directly to owner urgency.

Related Reading

• The new finance data layer
• Why AI finance projects fail
• Before another dashboard, fix the number you trust least
• Level services
• Level integrations
• Benchmark your company