Accounting Integration Outage and Recovery: What Finance Should Check

If the integration goes down, preserve the recovery boundary first

Record the last verified successful event, the first failed or skipped event, affected entities and record types, connector version, schema version, retry behavior, and any manual work performed during the outage.

Do not replay or re-import everything immediately. A recovery can create duplicates or overwrite later corrections if the team has not defined the affected population and idempotency behavior.

A connector can return to service while records remain missing, duplicated, rejected, or stale. Finance should compare the recovered population with the authoritative source and read the result back from accounting before declaring recovery complete.

Source and claim note: Public developer documentation from QuickBooks Online, Xero, Jobber, ServiceTitan, and NetSuite establishes that these systems expose integration surfaces. The diagnostic approach below is a Level operating pattern, informed by finance-side systems work. It is not vendor support guidance or a claim that any named product is defective.

What a sync log proves, and what it may not

A sync log can confirm that an invoice, customer, payment, bill, webhook, or export moved.

That is useful.

It may not answer whether:

• the transaction mapped to the right customer, job, property, and GL account
• revenue and cost landed in the intended period
• payment, credit, write-off, retainage, or deposit treatment agrees across systems
• the report includes the same status population on both sides
• supporting documents exist for an AR or AP question
• an exception has an accountable owner and next action

Those questions form the finance-side close process.

The connector recovery taxonomy

Classify the issue before trying to fix it.

Do not label an issue a bug until the evidence supports that conclusion. Many mismatches are configuration, mapping, timing, workflow, migration, or report-population questions.

Request the same-period detail

Pick a date range and export the detail from both systems. For each relevant record, compare:

• source record ID and accounting record ID
• record type, counterparty, job or project, and dimensions
• original amount, payment amount, credit or write-off, and open balance
• operational status and accounting status
• operational date, posting date, and report filter
• exception type, likely cause, owner, next action, due date, and remaining uncertainty

Do not start with two dashboard totals. A total can agree while records are duplicated, omitted, or mapped to the wrong job. The reverse is also possible: totals can differ temporarily because records are on opposite sides of a period cut-off.

For a blank same-period comparison template, use the field-software and accounting mismatch worksheet.

A synthetic example

This example is illustrative, not a client story or a claim about any vendor.

An operations report shows an invoice as open at month-end. The accounting AR report shows a lower customer balance. The invoice number and original amount match. The finance team compares payment detail and finds a partial payment posted in accounting after the field report was exported. The remaining difference is a credit that was applied to the customer but not linked to the job record.

The connection was not necessarily broken. The next actions are to align report timing, link the credit to the correct job where appropriate, assign an owner for the mapping rule, and confirm the next close includes the same record population.

What to prove before trusting a number

For an invoice, prove that the field job, customer, invoice number, amount, financial posting, supporting document, AR status, payment application, and expected cash treatment all agree.

For a bill, prove that the vendor, job or project, cost code, approval, receipt or PO when relevant, payment status, and job-cost treatment agree.

For payroll, prove the source journal, liability, cash settlement, and job-cost allocation. A clearing account can be appropriate when it represents a real handoff, but there is no universal payroll mapping instruction. Trace the full transaction before changing accounts.

For active jobs, keep WIP, open AR, open AP, and cost-to-complete logic distinct. They may be connected, but one report should not silently replace another.

The same discipline applies when comparing your operating results with the Level contractor benchmark. A benchmark can provide context for a defined metric, but it cannot repair a missing source record, decide a mapping rule, or substitute for reconciling your own system population.

What not to change first

Do not begin by deleting a transaction, rebuilding the connector, or changing the chart of accounts. Preserve the evidence first. Export the two detailed populations for the same cut-off, save the report settings, and choose one mismatched record that can be traced end to end.

For that record, identify the system that created it, the system expected to receive it, every status change, any payment or credit, the posting date, and the reporting dimensions. This small trace often separates a connection problem from a report filter, timing difference, mapping decision, or accounting treatment. Once the cause is known, the team can correct the rule and test the next population without creating a second unexplained difference.

Turn the close into an exception queue

A practical close does not ask a human to inspect every row. It produces a short queue of the rows where proof, dimension, timing, document, or policy treatment differs.

Each row needs a responsible owner, next action, due date, and clear note of what remains uncertain. That is the bridge between a technically connected stack and numbers an owner can use to make a decision.

Recover the full population, not only the failed message

After service returns, identify whether the connector retries automatically, requires a manual replay, or needs a bounded backfill. Reconcile the full affected source population to target records using stable IDs, counts, and control totals. Test create, update, cancellation, payment, credit, and other financially material paths that were affected.

If an API or export schema changed, version the mapping and preserve the old and new field definitions. Freeze write-enabled automation until required fields, types, signs, dates, dimensions, and refusal conditions pass on a controlled fixture. Then backfill from the last verified cutoff and read the result back from the accounting system.

Use vendor support for access failures, documented connector behavior, platform errors, retry mechanics, and schema questions. Use a finance-systems advisor for source ownership, accounting treatment, control design, reconciliation, cutover, and deciding what evidence makes the books reliable again.

For the category map, use the Financial Systems Field Guide. For a named pairing, see BuildOps and QuickBooks or BuildOps and Sage Intacct. For completed work that has not reached billing, use the separate revenue leakage review.

Related Reading

• How fast should contractors invoice?
• Job costing in QuickBooks for contractors
• WIP schedules explained
• Cash-gap calculator

Get a finance-side setup assessment

Level can assess the finance-side flows, mappings, controls, and ownership behind your existing systems, then prioritize the next actions. When records disagree, we can organize an exception queue that names the difference, likely cause, owner, next action, and remaining uncertainty.

This is not a vendor support desk or a promise to repair every data issue. It is a finance-side assessment for a contractor or financially complex service business with a material setup, migration, integration, control, or reconciliation question.

Assess my finance systems setup

FAQ

Is a green sync log enough to close an outage?

No. It shows connector activity, but recovery still needs the affected source population, target read-back, duplicate and skipped-record checks, and owned exceptions.

What should happen after an API schema changes?

Freeze affected writes, preserve the payload and error, version the mapping, test required fields and refusal conditions, backfill from a known cutoff, and reconcile the target population.

When should I call vendor support?

Call vendor support for product access, platform errors, documented connector behavior, retry mechanics, and schema changes. Use finance support for accounting policy, source ownership, reconciliation, controls, and close design.