Accounting Integration Outage and Recovery: What Finance Should Check

A few terms used below:

• AR and AP: unpaid customer balances and unpaid supplier bills.
• WIP and PO: work in progress and purchase order.
• Schema: the required record fields and their formats.
• Idempotency: preventing duplicate entries when a request is repeated.
• Backfill: rechecking or importing older records from a known date.
• Payload: the data sent in a request.
• Controlled fixture: a set of known test records.
• API and connector: an API is a software connection; a connector uses it or another supported method to move records between systems.
• Webhook: an automatic notice sent when something changes.
• Reporting dimensions: categories such as job, crew or location used to group financial results.
• Control total: a figure that the detailed records must add up to.

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 complete set of recovered records with the original source and check the resulting records in the accounting system 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 general-ledger 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.

Choose how much the automation is allowed to change

Read-only automation retrieves records without changing the books. A staged change prepares the exact proposed update for a person to review. Write-enabled automation can change records, so it needs approval, checks of the posted result and a clear process for investigating errors.

For skipped records, keep the source record ID, first occurrence, retry status, financial effect, person responsible, next action, due date and evidence of resolution. An incremental sync retrieves changes since its last checkpoint. Compare it periodically with a full list of the affected records: a successful run does not prove that earlier skipped items were recovered.

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 conditions that require human review 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 Accounting Software Integration Guides. 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. Compare all affected source records with the resulting records in accounting, and check for duplicates and skipped records. Give remaining differences an owner and a next step. Those differences stay unresolved until explained, and the responsible accountant must decide whether they prevent sign-off.

What should happen after an API schema changes?

Freeze affected writes, preserve the payload and error, version the mapping, test required fields and conditions that require human review, 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.