Job invoice-retry-creates-duplicate-invoices · revised 11 October 2026
Stop a retried automation from creating a second invoice in Xero or QuickBooks Online
Replaying, retrying or double-running one named invoice automation leaves exactly one invoice per source order in a test accounting file, and an unknown outcome is held for a person.
You might be seeing
- Two draft or approved invoices carry the same order reference, created minutes or hours apart
- A red or timed-out run is re-run by hand and the customer is billed twice
- Nobody can tell from the run log whether a failed create actually reached the accounting system
No passwords, keys, card details or admin invites needed to start.
What usually happened
The automation treats every attempt as a new business operation. It has no stable per-order identity carried into the invoice, no lookup before it creates, and no rule for a create whose response was lost, so any retry, replay or overlapping run can add another invoice for the same order.
Who it’s for: A founder, operations lead or developer whose automation creates customer invoices in Xero or QuickBooks Online and sometimes creates the same invoice twice after an error, a timeout or a manual re-run.
Usually starts when: A bookkeeper finds two invoices for one order, or a run that timed out is re-run and nobody can say whether the first attempt already created the invoice.
The result: After a replay, a concurrent double-run and a simulated lost response on synthetic orders, the test accounting file holds exactly one invoice per source order, and any order whose state is unknown sits in a held list for a person instead of being created again.
Check whether this job fits
Answer these from what you can see without sending logins, invoices or customer data. Nothing is submitted unless you choose to contact us; this is a fit check, not permission for us to touch your systems.
Checks you can run yourself
Count invoices for one order reference
In your accounting system, search for one recent order reference using the field the automation fills. Do not edit or delete anything.
Look for: More than one result means a duplicate exists. Zero results for an order you know was billed means the reference is not stored in a searchable field, which is a design gap rather than a retry bug.
What you get
- The change as a pull request or an exported configuration, with a note on where the identity is stored and how the lookup works
- A test log for the replay, concurrent and lost-response cases with invoice counts per order, redacted
- A one-page rule sheet: what the automation does on zero, one and several matches, and who releases a held order
Included
- One named automation, code or low-code, that creates invoices in one Xero organisation or one QuickBooks Online company
- A stable per-order identity, carried into a searchable field on the invoice, and a find-before-create step keyed on it
- Use of the vendor request-key mechanism on the create call where the documentation supports it, with its limits recorded
- A held-exception list for orders whose outcome is unknown, conflicting or whose lookup is unavailable
- A durable per-order claim, such as a unique record or a lock written before the create call, so two runs started together cannot both create
- Replay, concurrent-run and lost-response tests on a demo or sandbox file
Not included
- Deleting, voiding or merging invoices that are already duplicated: your finance owner decides each one
- Rebuilding the whole automation, adding a new queue or changing which system owns invoice numbers
- Repairing field mapping or tax fields on the invoice itself
- A guarantee about vendor behaviour the documentation does not state, such as how long a request key is remembered
- Bookkeeping, tax, audit or any accounting advice, including deciding how a transaction should be treated in your accounts
- Changing posted, reconciled or locked-period transactions: your accountant or account holder decides and performs those
- Live changes: your authorised account holder applies any agreed change and holds the production keys
How we know it’s done
Agreed with you before work starts. Each check produces evidence you keep.
Replaying the same three synthetic orders three times, once after a simulated lost response, leaves exactly three invoices in the test file, one per order.
Evidence: The order list, the run log and a per-order invoice count from the test file, redacted.
Two runs started at the same moment for the same synthetic order leave one invoice, or one invoice and one held entry naming that order.
Evidence: Timestamps of both runs, the invoice count and the held list.
An order whose lookup is made unavailable creates no invoice and appears in the held list with the reason.
Evidence: The test setup note, the run log and the held list.
An order replayed with the same identity but a changed amount is held as a conflict; it neither overwrites the invoice nor creates another.
Evidence: Before and after invoice values and the held entry.
Sign-off. You inspect the named test evidence and sign off before payment. Your authorised account holder performs and verifies any live change, and decides what happens to records already posted.
If it fails. If an agreed check does not pass, you do not pay for this fixed scope. We hand over the findings and agree whether to stop or re-quote; no surprise work and no change to your live records.
When it fits, and when we stop
It fits when
- You can name the automation, the system it writes to and the field where a source order reference can be stored
- A demo organisation (Xero) or a sandbox company (QuickBooks Online) can receive synthetic invoices without sending anything to a customer
- The automation can run against that test target, or its create step can be exercised on its own
- A person on your side can approve the held-exception rule and the live switch-over
- Somewhere durable can hold a per-order claim, such as a table with a unique key or a lock the platform provides
- Real financial records, customer data and keys are handled only after written agreement, through a secure handoff we agree with you; the first enquiry and the fit check use invented or redacted examples
We stop and tell you if
- The automation cannot be pointed at a test target and every run would create real invoices
- The source has no stable order identity, so the first job is to define one with you under a separate quote
- Invoices must be created in several accounting systems at once, or by several unrelated automations, which needs a wider scope
What could go wrong
Before you merge, closing the pull request leaves your automation unchanged. After the live switch, your developer can revert the change or re-enable the previous path. Invoices already created are not touched by this job.
Scroll the table sideways to read it all.
| Risk | How we handle it |
|---|---|
| A lookup that returns nothing is read as proof that no invoice exists, so a delayed or in-flight invoice is created again. | An empty result is only trusted together with the stored identity and the agreed wait; otherwise the order is held. The per-order claim and the concurrent-run tests cover the in-flight case. |
| A request key is reused after the vendor has forgotten it, or reused with changed contents. | The job records each vendor limit stated in its documentation and does not depend on the key alone; the lookup is the durable control. |
| Test runs write to the live file by accident. | Tests run only against the demo or sandbox target you create, with outgoing invoice emails unavailable or switched off. |
An independent reviewer checks that the test counts really come from separate runs, that a lookup failure cannot fall through to a create, and that no real customer data appears in the evidence. Your finance owner approves the held-exception rule.
How we deliver
We arrange the work and independent review, then show you the result against the agreed checks. You keep authority over your systems.
- Agree in writing the automation, the target file, the order identity, the field that stores it and the rule for held orders
- Reproduce a duplicate on the demo or sandbox file with synthetic orders and record the invoice count per order
- Carry the order identity into the invoice, add the durable per-order claim and the find-before-create step, and use the vendor request key only as a second layer where it is documented
- Add the held list for unknown, conflicting or unreadable lookups so none is created again automatically
- Run the replay, concurrent and lost-response tests and capture counts per order
- Independent review of the diff, the test log and the rule sheet, then hand over for your developer to merge and your account holder to switch live
This is a one-off job, not emergency cover or a subscription. We confirm eligibility, the total price, a start window and a delivery date before you accept. Work starts only after agreed inputs, secure access, any licences and necessary permissions are in place. Platform and supplier charges are excluded unless the written quote includes them. No charge or booking is created by an enquiry.
Need to keep it working?
If retries are frequent, discuss a standing check that counts invoices per order reference after each run, as a separate agreement.
Ongoing work is separately scoped and quoted: no monitoring, response-time guarantee or automatic subscription is included in this job.
Explore an ongoing engineering lane, or mention the responsibility you need in your enquiry.
What you can check
This is a new service. We have not delivered this job for a client yet.
Other ways to get this done
- If your developer can change the automation, Xero documents an Idempotency-Key header for creating records, and Intuit documents a request id for QuickBooks Online; read their limits before relying on either. developer.xero.com
- Ask the vendor of the connector or integration you use whether it can search for an existing invoice before creating one.
Questions
Can you delete the duplicates I already have?
No. Choosing which invoice stands, voiding or deleting is your finance owner's decision. We can give you the matching list by order reference so the decision is quick.
Does the vendor request key solve this on its own?
Not on its own. Its documented retention and conditions are limited, so the stable order identity and the lookup remain the lasting control. The job states what each vendor documents and what it does not.
What if my automation is a low-code scenario?
It can fit if the create step can search before it creates and the scenario can run against a test file. If it cannot, the fit check says so before any price is agreed.
Send an enquiry
Send us
- Which system it writes to (Xero or QuickBooks Online) and how the automation is built, in a few sentences
- An invented order reference and the field it would be stored in, plus what currently happens after a failed or timed-out run
- Roughly how often runs fail or are re-run by hand
- Do not send credentials, bank details, invoices, customer records or confidential code in the first enquiry
Later, once you agree
- Read access to the automation definition or code through the agreed route, with secrets held by you
- A demo organisation or sandbox company and test credentials created by you for this job
- Your written rule for what counts as the same order and what to do when its contents change
- A secure, company-controlled handoff route agreed in writing before any access; no passwords, keys or customer records by ordinary email
You keep the live accounting organisation, payment accounts, production keys and every customer and financial record. We work on an authorised demo, sandbox or synthetic copy through a company-controlled handoff, never a personal login. Your authorised account holder approves and performs any live change and checks the result under their own keys.
Email fallback: open your mail app
If website submission is unavailable, review and send the fallback email yourself. An email fallback is not a website receipt. Or write to hello@syntheticindustry.ai with “invoice-retry-creates-duplicate-invoices” as the subject.