--- title: "Delayed accounting sync: when should reminders pause?" canonical: https://www.billabex.com/en/blog/delayed-accounting-sync-pause-reminders/ lang: en alternate: https://www.billabex.com/fr/blog/synchronisation-comptable-retard-suspendre-relances.md updated: 2026-09-26 index: https://www.billabex.com/llms.txt --- # Delayed accounting sync: when should reminders pause? The dashboard says “sync completed at 9:12”, but a customer says they paid yesterday. Should finance pause every reminder, wait for another attempt or investigate only that invoice? The answer depends on what the successful sync actually covered. A working connection can still leave old payment data, a missing credit note or one legal entity in an error state while the other entities have updated correctly. To decide, finance needs a clear operational picture: through which point are the relevant records verified, for which accounts, and with what known exceptions? The time of the latest technical exchange does not always answer those questions. The aim is to define a targeted pause where reliability is uncertain, followed by a restart based on corrected balances and the conversations that took place during the interruption. ## Ask what the latest success actually means Distinguish when a sync was attempted, when it finished and the period of data it actually incorporated. A process starting at 9:00 may finish at 9:12 while importing a file whose contents stop at midnight. Another may succeed for invoices while failing for payments. In either case, displaying only 9:12 suggests freshness that does not describe the balance available for a responsible payment reminder. Microsoft explains incremental loading using an old and a new boundary, often based on when records were last modified. That technical documentation helps explain why execution time and covered data are different pieces of information; it does not establish an optimal reminder frequency. [Microsoft Learn, incremental loading](https://learn.microsoft.com/en-us/azure/data-factory/tutorial-incremental-copy-overview). Ask for a statement such as “entity A payments incorporated through 8:00, credit notes outstanding since yesterday”, rather than one overall green indicator. If your provider cannot supply that detail, document the limitation and the alternative verification process. Missing visibility should remain an uncertainty. It should not become an assertion that nothing has changed for the customers affected by the interruption or the records awaiting another attempt. ## Identify which missing information could make the message wrong Invoices, payments, credit notes and customer replies do not necessarily travel through the same route. Delayed contact data can affect the recipient; delayed payment records can affect the amount requested; a recent dispute can affect the next appropriate action. Specify which risk the pause addresses, because repairing one flow does not automatically resolve the others. A message may require more than a fresh invoice record before it becomes suitable to send. Xero's public specification illustrates another distinction: an invoice change notification identifies the changed resource and where to retrieve it. Receiving that notification alone therefore does not establish that your application has recalculated the relevant balance. This example explains an integration mechanism; it does not claim Billabex uses that architecture. [Xero, notification schema](https://raw.githubusercontent.com/XeroAPI/Xero-OpenAPI/master/xero-webhooks.yaml). When a customer reports a payment missing from the application, first follow the process for [tracing cash against an open invoice](https://www.billabex.com/en/blog/payment-received-invoice-still-open-tracing-unallocated-cash/). If the receipt is already in the accounting system but absent from collections, investigate transmission or application of the records. If accounting also lacks the receipt, a perfectly functioning sync from that source will not be enough to make the payment appear. ## Define the scope of the pause before its duration A fault isolated to one entity does not always justify stopping other entities whose records remain reliable. Conversely, if affected accounts cannot be isolated, pausing only the invoice that triggered the alert may allow other incorrect messages to leave. Choose the smallest scope whose boundaries can actually be established: a customer, a data flow, an entity or, where necessary, the whole portfolio. The scope must reflect evidence rather than convenience. Acceptable delay depends on the way your business operates. A company reconciling receipts once each day cannot promise instantaneous knowledge of bank movements simply by transferring accounting records every five minutes. Set release conditions around actual posting schedules, customer conversations and available verification. The thresholds you choose become internal rules to test; they should not be presented as a universal industry standard for safe or effective collections. A pause need not stop all useful work. Colleagues can assemble documents, answer a request for a copy invoice or seek clarification without asserting an uncertain balance. They can also handle an individually verified case if your procedure permits that exception and the other conditions for contact are satisfied. Record the manual check and its scope so that one cleared account does not accidentally release every neighbouring account. ## Examine a fictional batch of eighty reminders Suppose eighty messages have been prepared at 9:00 in a simulated example. Fifty belong to entity A, whose payments remain at the last confirmed state of 18:00 the previous day. Thirty belong to entity B, successfully updated through 8:45. If the separation between entities is verified, A's fifty messages are held while B's thirty continue through their usual checks. This does not mean those thirty are automatically approved for transmission. At 10:00, recovery of A's missing records reveals twelve fully paid invoices, three partly paid invoices, two credit notes requiring consideration and thirty-three cases without a relevant change. The total is 12 + 3 + 2 + 33 = 50. These groups are assumed to be separate for the calculation. Twelve messages should be removed, five reviewed for their amounts and thirty-three reassessed before any eventual send. Calling these seventeen “payments recovered” would be incorrect: the receipts already existed, partial payments have their own amounts, and credit notes are not cash. Claiming the pause prevented seventeen certain errors would also require evidence about what the previous controls would have done. The example measures cases whose prepared state changed: 17 / 50 = 34% of the held batch. It is not an observed software failure rate or a product performance claim. ## Verify recovery beyond a restored connection Recovery should establish that the missing period has been covered and changes applied to the correct accounts. Another successful response from the source does not, by itself, demonstrate that the backlog has been absorbed. Ask how incomplete responses, retrieval limits and remaining errors are identified. The explanation should be understandable to the colleague authorising reminders, even where a technical team performs the underlying investigation and repair. As a documented example, Intuit described change capture in August 2023 as limited to the **previous thirty days** and **1,000 objects per response**, recommending shorter intervals where the ceiling was reached. Those limits belong to that particular mechanism, rather than every connector or a software recommendation for France. They illustrate why a lengthy interruption needs a verified recovery approach. [Intuit Developer, CDC](https://medium.com/intuitdev/building-smarter-with-intuit-stay-in-sync-with-cdc-171f8094dd37). After recovery, also check information received during the pause: [payment promises](https://www.billabex.com/en/blog/verifiable-payment-promises/), new documents and approved credit notes. Restored accounting data must not override a recent customer response. A message prepared before the incident may therefore need a new decision even when its amount remains unchanged. The customer should not receive a reminder that ignores the conversation your team has just had with them. ## Make responsibility for restarting explicit Assign someone to verify the records and an authorised person to decide on restart, according to your organisation. Record the scope, last reliable data, correction obtained and remaining exceptions in the [activity trail](https://www.billabex.com/en/blog/collections-audit-trail-automation/). If the incident recurs, those facts will support comparison of causes instead of recreating the same discussion from a screenshot showing a green connection indicator and little else about the affected balances. During a demonstration of [Billabex integrations](https://www.billabex.com/en/product/integrations/), use this scenario to ask what your configuration shows during a delay, how relevant data is verified and who handles exceptions. A useful answer should let you decide which messages may proceed, which must wait and what evidence will allow them to resume. That specific operational decision is what a sync status needs to support for a finance team managing customer relationships. ## Sources - Microsoft Learn, 31 March 2026: [boundaries and incremental loading](https://learn.microsoft.com/en-us/azure/data-factory/tutorial-incremental-copy-overview). - Xero, public specification consulted 7 September 2026: [notifications and changed resource references](https://raw.githubusercontent.com/XeroAPI/Xero-OpenAPI/master/xero-webhooks.yaml). - Intuit Developer, 24 August 2023: [change capture and CDC limits](https://medium.com/intuitdev/building-smarter-with-intuit-stay-in-sync-with-cdc-171f8094dd37).