Connecting sales and accounting: retry without duplicate transactions
Sending again can create another business record
When connecting sales and accounting systems, missing data is not the only problem. Sometimes the receiving system accepts a transaction, but a network interruption prevents the sender from receiving the response. A user then sends it again, potentially creating another record if the process does not recognize the original request. Define retry handling before going live, focusing on the business effect that should occur only once. A successful-send message alone is not an adequate acceptance criterion.
Agree on what counts as the same transaction
Start with a business rule: an order from a particular source system must create which kind of accounting document? Define a reference that can be traced to its origin. It should distinguish resending the same request from amending or cancelling that transaction. Do not classify records as duplicates simply because customer names or amounts match; the same customer may legitimately buy items at the same price several times. Have business owners approve the rule before technical design begins.
A tool's capability has boundaries
Microsoft explains that Azure Service Bus can identify duplicate messages by MessageId within a configured time window when the feature is enabled. The useful discussion principle is that the system must recognize the same work and that the scope of duplicate checking must be understood. This does not mean all accounting systems have the same capability, or that enabling a queue feature prevents repeated effects at every stage. Ask separately how the receiving point, document creation and subsequent steps perform their checks.
Give uncertain results a defined resolution path
Distinguish at least pending requests, confirmed outcomes, failures with known causes and cases where it remains unclear whether the destination completed the work. For the last category, assign a reviewer, a lookup method using the reference, and conditions that permit a retry. Staff should not immediately create an extra manual document while automatic retries are still running. Retain necessary request and response history, restricting access to customer information by role.
Test failures using sample data
Before launch, submit the same request twice, simulate a received request whose response is lost, and submit an amendment that must be distinguished from the original. Check document counts, related amounts and downstream actions such as stock deductions, not just the status displayed on screen. Also test two legitimate purchases by the same customer for the same amount so that valid work is not discarded as a duplicate. Define expected outcomes and retain test results using sample data.
Prepare an integration brief the business can accept
Chawinnix provides IT systems, AI and automation, and accounting-system services. Organizations discussing integration can prepare a system list, sample data, rules distinguishing original work from amendments, and an owner for uncertain outcomes. Ask proposals to identify duplicate-checking points, tracking methods and tool limitations. Fast data transfer is only part of the work; the system should also explain what effect each transaction has already produced.
