Review accounting sync status

Purchasing → Accounting sync shows every approved vendor bill's status against your connected accounting system, one row per bill.

What each column means

• Match status — whether the bill's lines reconcile against the purchase order and receipt (unmatched, matched, exception, or matched-and-approved).
• Approval status — whether an office/manager has signed off on the bill for payment, independent of the match result.
• Sync status — the bill's accounting-sync outcome: queued, syncing, synced, failed, or needing attention.
• Last attempt — when the sync pipeline last tried to push this bill.
• External ID — the bill's id in the connected accounting system, once synced.

When QuickBooks isn't connected

If your shop hasn't connected QuickBooks yet (Settings → Integrations), approved bills show Ready for export instead of a sync status — nothing is pushed anywhere, but the bills are real and ready. Use Export CSV at the top of the screen to hand the list to your bookkeeper directly; it's the same data either way, so the download never disagrees with what's on screen.

Once QuickBooks is connected, the same screen switches to showing each bill's real delivery status instead.

Disable and rollback behavior

Disabling Accounting sync is the safe application rollback for new work. It prevents a newly approved bill from creating an accounting outbox row and hides accounting CSV exports. It does not delete vendor bills, earlier delivery attempts, external IDs, mappings, or conflicts; the Accounting sync and Materials reconciliation reports continue to expose that history.

An outbox row that already exists is different from a newly approved bill. The Accounting sync table continues to show its durable queued, syncing, delivered, failed, or needs-attention state while the capability is off. In Materials reconciliation, an approved bill without a terminal result is counted as Disabled for the selected branch, while delivered, failed, and conflict outcomes remain visible.

Capability disablement does not cancel an outbox row that was already queued or claimed. The background worker checks the QuickBooks connection before delivery, but does not re-check the capability. If a rollback must also stop existing queued rows, disconnect QuickBooks under Settings → Integrations after disabling the capability. Disconnecting clears the integration tokens and makes later attempts retry instead of push; an attempt that already passed its connection check may still finish, so verify both Thermal and QuickBooks afterward.

Investigate a failed or needs-attention bill

The current report is read-only; it does not include a requeue or conflict-resolution button. Use the bill ID, Last attempt, External ID, and report status when escalating to an authorized data operator.

Before requeueing a dead-lettered row, the operator should inspect its latest error and classify it:

• Retry only after a transient connection, authorization, rate-limit, or adapter problem is confirmed fixed.
• For a validation, permissions, deleted-record, or missing-vendor failure, repair that root cause first. A blind retry will dead-letter again.
• For a conflict, inspect the pending conflict's recorded local snapshot and conflict fields, then compare the Thermal bill with the QuickBooks bill. Decide which record is authoritative before changing either side.
• Confirm whether QuickBooks already contains the bill. Provider success followed by a local failure can leave Thermal without a delivered acknowledgement even though QuickBooks accepted the request.

Requeue is a controlled data operation against the existing outbox record, not a new approval and not a new outbox row. Preserve the row's ID because that exact ID is sent to QuickBooks as requestId on every attempt. Reusing it lets QuickBooks collapse a retry into the same logical create. The operator should reset the existing row's retry state only after the root cause is fixed, keep its organization, provider, entity, internal bill ID, payload, payload hash, and row ID unchanged, and return the bill's sync snapshot to pending. Do not delete and recreate the row.

Resolve a conflict or incorrect crosswalk

For a genuine local-versus-QuickBooks divergence:

1. Compare the pending conflict's local snapshot and conflict fields with the current QuickBooks bill.
2. Correct the authoritative business record. If the QuickBooks bill is the intended record, repair Thermal through an approved data correction; if Thermal is authoritative, correct QuickBooks before retrying.
3. Verify the vendor-bill crosswalk: the internal vendor-bill ID must point to the intended QuickBooks bill ID, and the vendor bill's External ID must agree. An authorized data operator must correct an incorrect mapping before retry.
4. Record the conflict as resolved with the responsible operator and resolution time, then requeue the same outbox row while preserving its ID and requestId identity.

Do not resolve a conflict by deleting the vendor bill, outbox row, external mapping, or conflict evidence. Forward repair preserves the audit trail and prevents a replacement row from issuing a different provider request ID.

Verify the repair

After the worker runs again:

1. Confirm Last attempt advanced on Purchasing → Accounting sync.
2. Confirm the bill becomes Synced and has the expected External ID, or that a remaining failure gives a new, actionable reason.
3. Open Purchasing → Reconciliation for the bill's branch. Confirm the approved amount appears in exactly one accounting state and the partition delta is zero.
4. Confirm the QuickBooks bill exists exactly once and its amount, vendor, date, and bill number match the intended record.
5. Have the data operator confirm the existing outbox row is delivered, its mapping agrees with the bill's External ID, and no pending-review conflict remains.
6. If the capability was disabled for rollback, leave it off until these checks pass. Re-enable it only for the intended branch, then verify one newly approved test bill creates one outbox row and reaches one terminal result.