--- title: "A replayed import should not trigger duplicate reminders: how to test it" canonical: https://www.billabex.com/en/blog/replayed-import-duplicate-reminders/ lang: en alternate: https://www.billabex.com/fr/blog/import-rejoue-doublons-relances.md updated: 2026-10-24 index: https://www.billabex.com/llms.txt --- # A replayed import should not trigger duplicate reminders: how to test it An accounting synchronisation stops partway through. Support suggests replaying the last import and confirms that invoices are visible again. An hour later, several customers receive a second identical reminder. Yet the invoice count has not increased. The incident exposes two separate requirements: recognising data already received and recognising an action already performed. A tool can prevent duplicate case records while still repeating a message. Evaluating a collections integration therefore means checking the customer-visible result in an environment designed for testing. The finance team does not need to prescribe the connector's architecture. It does need to define the business outcomes that must remain true when a file or notification is delivered again. ## Define what repeating without an extra effect means Technical teams use the term idempotence when repeating the same operation adds no new business effect. Translate that into your case: one invoice remains one invoice, one receipt is not counted twice and one reminder decision does not create several sends. AWS explains that apparently identical requests can nevertheless represent different intentions. Its technical library recommends making the request's intent identifiable instead of always inferring duplication from content alone. [AWS Builders' Library, safe retries and idempotent APIs](https://aws.amazon.com/builders-library/making-retries-safe-with-idempotent-APIs/). In collections, that prevents the opposite mistake too: suppressing a legitimate later reminder because its text resembles an earlier one. The test should distinguish retrying the same action from authorising a new action on another date. It does not require that a customer never be contacted again. ## Preserve identity beyond the filename Renaming a file does not create new invoices. Reordering its rows does not either. To identify an item, the system must recognise its source and identifier within the relevant scope, including the issuing entity. Matching only the displayed invoice number can confuse two companies. Odoo 18 documents consistent external identifiers for updating records through imports. It warns that changing or removing an identifier can create a duplicate. This import rule illustrates persistent identity without proving the behaviour of another integration. [Odoo 18, exporting, importing and updating data](https://raw.githubusercontent.com/odoo/documentation/18.0/content/applications/essentials/export_import_data.rst). Prepare an identical file, a renamed copy and a copy with reordered rows. The expected business result should stay stable. The distinction between [invoice numbers and legal entities](https://www.billabex.com/en/blog/duplicate-invoice-numbers-legal-entities/) helps select references that make the check dependable. Retain the original source references in the test notes. If a mismatch appears, the reviewer should identify the affected invoice without relying on a screen label that may have changed during import. ## Build a case where totals cannot hide the problem Consider a simulation with ten customers and forty invoices of €2,000, initially totalling €80,000 open. Submit the import three times. That represents 120 rows processed across the transmissions, but still forty business invoices and ten customers. An outstanding balance of €240,000 would expose obvious duplication. Checking only the €80,000 total is insufficient. The tool might create eighty additional invoices and exclude them from the displayed total. Ask for active document counts, identifiers and conversation relationships. Repeated import history is normal; a second debt for the same document is not. For a separate test wave, select six customers with two €2,000 invoices each: twelve invoices and €24,000. The test rule specifies one grouped message per customer for this same decision, so six messages are expected, not twelve. This grouping is a test assumption, not a universal reminder policy. If replaying the import three times produces eighteen messages for that one wave, there are twelve extra sends. The count has tripled even though invoices and balances remain correct. The report should identify the communication-level discrepancy rather than simply state “no duplicate imports.” ## Test recovery after an uncertain result The most revealing case occurs when a service performs an operation but its acknowledgement never reaches the caller. Retrying may then repeat an action that already succeeded. Ask for a controlled demonstration with test recipients and communications isolated from production. Stripe documents automatic event-delivery retries lasting up to three days in live mode. It also explains that events may arrive repeatedly and out of generation order. Those behaviours show why integrations need recovery handling; they do not describe your reminder cadence. [Stripe, event delivery and duplicate handling](https://docs.stripe.com/webhooks). The test report should distinguish an attempt, acceptance by the sending service and the known outcome. If confirmation is missing, the system should expose and resolve the uncertainty before a potentially duplicate customer contact. An “error” entry does not prove that nothing was sent. Observe the actual test inbox as well as the application log. A system can report one logical message while the delivery service has accepted two separate submissions. ## Check old data cannot reopen a paid invoice Return to the six simulated customers. Before sending, one pays both invoices, totalling €4,000. The receipt is verified and allocated. The wave's remaining scope becomes five customers, ten invoices and €20,000. Now replay the older extraction that still showed €24,000. The case should retain the effect of the recent receipt or require explicit resolution of the data conflict. An older import is not fresh evidence of non-payment. Blindly applying “the last received value wins” can reverse the chronology of the actual events. This complements the article on [invoice changes after a reminder](https://www.billabex.com/en/blog/invoice-changed-after-reminder-versions/). In both cases, the arrival date of information differs from the event date it describes. The test should also inspect messages prepared before the receipt arrived. Use a partial receipt as a further variation if that is common in your portfolio. The expected outcome is then an updated balance and appropriate request, rather than either a fully closed case or an unchanged original demand. ## Include a genuinely new authorised action An overly broad safeguard may suppress both the duplicate and all subsequent reminders. Add a scenario where, after reviewing the case, someone actually authorises a new action. The tool should distinguish it from the earlier retry while accounting for intervening receipts, replies and agreements. AWS also notes that how long a request remains recognised depends on the service and its contract. Ask how far back supported recovery extends and what happens beyond that period. A successful five-minute replay does not establish behaviour several days later. The acceptance result should describe its tested window. That makes it possible to judge whether a real outage falls within the demonstrated behaviour or requires additional review before recovery. ## Ask for evidence finance can understand A useful deliverable contains the input files, expected amounts, resulting records and messages actually produced. A [collections audit trail](https://www.billabex.com/en/blog/collections-audit-trail-automation/) helps connect those elements without confusing technical attempts with customer communications. To assess your workflow, explore [Billabex integrations](https://www.billabex.com/en/product/integrations/) using these replay scenarios. Ask for observable outcomes and the relevant connector's limits. A general reliability claim cannot replace checking three practical results: the same case, the correct current balance and only the action that was actually authorised. ## Sources - AWS Builders' Library, Making retries safe with idempotent APIs. - Odoo 18, Export and import data, identifiers and repeated imports. - Stripe, Receive Stripe events, delivery and duplicate handling. Sources accessed 7 September 2026.