Webhooks vs scheduled accounting sync: design for both speed and completeness

Webhooks notify an integration when an event occurs. A scheduled sync checks a source at an agreed interval. For accounting, the useful question is whether the design can deliver the right record on time, detect what it missed, and recover without posting twice. A combination of event notifications and scheduled verification can answer those requirements.

Stripe documents that webhook events can arrive out of order and can be delivered more than once. Intuit's QuickBooks Online guidance recommends ChangeDataCapture checks to compensate for missed events and describes an additional daily check. These primary sources support a practical conclusion: receiving notifications is not, by itself, proof that the accounting data is complete.

A customer payment may need to update an account status quickly, while a management report may need verified totals only at a scheduled time. Define the required delay for each use rather than applying the phrase real time to the entire finance process. Quick notification and reviewed accounting are different stages of the same flow.

Ask which timestamp the integration displays: when the source changed, when the notification arrived, when processing finished, or when the ledger accepted the record. A dashboard showing a recent connection time can still conceal old unprocessed work. Finance needs to see the age of the oldest unresolved item as well as the latest successful run.

For a high-volume source, agree whether the ledger needs every event immediately or whether an approved summary is posted later. The event mechanism does not determine the appropriate accounting granularity.

Use a demonstration in which a payment update arrives before the corresponding invoice is available to the integration. The system should have a documented way to retrieve the required record or hold the item for recovery. It should not create an unrelated invoice merely to make the payment import succeed.

Then deliver the same event again. Stripe advises tracking event identifiers and, in some cases, the affected object and event type to identify duplicates. Ask the implementer to show how that becomes one accounting action. A second notification should not automatically mean a second receipt or journal entry.

Finally, update an already imported record. The design must distinguish a duplicate notification from a legitimate later change. Finance should be able to identify the original record, the accepted revision, and the treatment of any closed-period impact.

Neither mechanism removes the need for record identifiers, controlled mapping, and reconciliation. Evaluate what the proposed implementation does when those controls are exercised.

Disconnect a test integration after the source accepts a transaction but before the ledger confirms it. On recovery, the team should establish whether the accounting record already exists before attempting another write. This is the practical purpose of duplicate-safe processing, often called idempotency: repeating a request should not repeat its business effect.

For scheduled queries, agree how the process resumes after a partial batch. Include pagination, changed records, deleted or voided objects where supported, and the source's available history. A saved timestamp alone may be insufficient if records share a time or become visible late. The developer should explain the supported recovery boundary in terms finance can review.

Keep a route for items that automatic recovery cannot resolve. The reviewer needs the source record, intended accounting action, error, and prior attempts. Retrying indefinitely without an owner hides a backlog.

At the agreed interval, compare source counts and financial totals with accepted ledger records and documented exceptions. Separate pending, deliberately excluded, rejected, and completed items. A zero-difference result is meaningful only when both sides cover the same entities, currencies, transaction types, and period.

Retain the reconciliation result with the relevant import run or summary. The close reviewer should be able to explain an unsettled or unposted balance without reading application logs or asking a developer to reconstruct the period.

Select event-driven updates where their timing helps a defined workflow, and use scheduled verification where it establishes completeness or supports recovery. Confirm the exact source APIs, event coverage, limits, and support commitments in the implementation proposal.

Accept the integration after the team demonstrates ordinary processing, interruption, duplicate delivery, late changes, and reconciliation. The useful outcome is a dependable accounting flow with visible exceptions and clear ownership, rather than a fast connection whose missing records are discovered at month-end.