Job xero-rate-limit-drops-invoices · revised 11 October 2026
Make a bulk Xero invoice run finish every order, or list exactly which ones it held
A synthetic run of 150 orders against a simulated limit of 60 calls a minute, with a simulated 429 and an interruption, ends with every order created, already present or held, and counts that add up.
You might be seeing
- Invoice counts in Xero fall short of the source for busy days only
- Logs show too-many-requests responses followed by a job that continues or stops without recording which orders were skipped
- A re-run fills some gaps but creates other invoices twice
No passwords, keys, card details or admin invites needed to start.
What usually happened
The job sends requests faster than Xero allows per connected organisation, treats a rate-limit response as an ordinary failure, and keeps no durable record of which source orders are created, pending or failed. Orders are dropped silently or the whole run restarts and repeats work.
Who it’s for: A developer, operations lead or finance owner whose month-end or nightly job posts many invoices to Xero and finds some orders never arrived.
Usually starts when: After a busy period the number of invoices in Xero is lower than the number of source orders, and the job log shows rate-limit errors or a run that stopped partway.
The result: A synthetic run of 150 orders, sent one call per order against a simulated allowance of 60 calls a minute so that it needs more than one minute of allowance, with a simulated rate-limit response and an interruption, finishes with every source order either created, already present or listed as held with a reason, and those three counts add up to 150; an order left in doubt by the interruption is held, not 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
Compare one busy day
Pick one busy day. Count the source orders that should have an invoice, then count invoices in Xero for the same date. Do not re-run anything.
Look for: The size of the gap and whether the missing orders cluster at the end of the run, which is typical of a limit being reached.
What you get
- The change as a pull request, with the pacing settings and the checkpoint design described
- A test log with the created, already-present and held counts per run and the request pace, redacted
- A held-order list format and a short note on how to release or retry held orders
Included
- One named job that posts invoices to one Xero organisation in bulk
- A request pacer that respects the documented concurrency and per-minute ceilings and the wait the response asks for
- Batching of creates where Xero supports it (Xero documents up to 50 invoices in one call), with each returned item's own status checked rather than the call status alone
- A durable checkpoint of the state of each source order so a stopped run resumes without repeating work, with any order left in doubt held for a person
- Tests with a simulated rate-limit responder: the pace test sends one call per order against a simulated allowance of 60 calls a minute, so 150 orders need more than one minute of allowance; the batch test sends batches of 10 with one invalid order; and a run on a Xero demo organisation within the limits
Not included
- Raising Xero limits or changing your Xero plan; the limits are Xero's
- Preventing duplicate invoices from retries beyond the checkpoint, which is a separate job
- Rewriting the job into a different architecture or adding a queue product
- Backfilling past months of missing invoices in your real organisation, unless agreed as its own project
- 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.
A synthetic run of 150 orders, sent one call per order against a simulated allowance of 60 calls a minute so it needs more than one minute of allowance, with a simulated rate-limit response at call 60, ends with created + held + already-existing equal to 150.
Evidence: The three counts, the order list and the request log with the clock the test used.
In the same run the request log shows no more than 60 calls in any minute and no more than 5 in flight at once, unless a lower ceiling was agreed in writing.
Evidence: A per-minute request count and the maximum concurrency from the log.
A run stopped halfway and restarted creates only the orders still pending; no order the checkpoint records as created is created again, and an order that was in flight at the stop is held as in doubt.
Evidence: Checkpoint states before and after the restart and the invoice count.
In a batch of 10 orders where one is invalid, that order appears in the held list with Xero's reason and the other nine are created and counted.
Evidence: The held list and the batch response, redacted.
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 job, how often it runs and roughly how many invoices a busy run posts
- A Xero demo organisation can receive invented invoices, and a test double can return rate-limit responses
- The job has a stable source order id, or one can be agreed
- A person on your side can approve the held-order handling
- 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 shortfall is caused by validation errors or a failed connection rather than rate limits
- The job must write to several Xero organisations at once with shared limits that need a wider design
- No stable order id exists and none can be agreed
What could go wrong
Before merge, closing the pull request leaves the job unchanged. After merge, your developer can revert it; the checkpoint store holds only order ids and states and can be dropped. Invoices already in Xero are not modified by this job.
Scroll the table sideways to read it all.
| Risk | How we handle it |
|---|---|
| A batch call returns success while individual invoices failed validation, so orders look created when they are not. | Each returned item's status is checked and failures go to the held list; a test includes one invalid order. |
| Resuming after an interruption repeats an order that the first run created. | The checkpoint records state per order before and after each call, an order in flight at the stop is held as in doubt rather than created again, and the resumed run is a named acceptance test; full duplicate prevention is a separate job. |
| Tests consume the real allowance of a live organisation. | Tests use a simulated responder and a demo organisation, never the live connection. |
An independent reviewer checks that the counts add up in every test, that a rate-limit response never counts as success, and that the pacing ceiling is not exceeded in the request log.
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 the job, the pacing ceiling you are comfortable with, the order id and the held-order rule in writing
- Reproduce the shortfall with a test double that returns rate-limit responses and record created, already-present and missing counts
- Add the pacer, honour the wait the response requests and batch creates where Xero allows
- Check each returned item's own status and record the state of each order in a durable checkpoint
- Run the 150-order paced run against the simulated 60-calls-a-minute allowance, the simulated limit, an interruption and a resumed run, and capture the counts
- Independent review of the diff and the counts, then hand over for your developer to merge
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 runs keep growing, discuss a standing check of run counts against source counts 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
- Xero publishes its per-organisation limits and how to read the remaining allowance; your developer can add pacing from that page without us. developer.xero.com
- Xero's guidance for creating invoices says up to 50 invoices can go in a single call, which helps avoid hitting rate limits. developer.xero.com
- Xero's requests and responses reference describes summarizeErrors=false for bulk calls, so each item comes back with its own status. developer.xero.com
Questions
Can you make Xero allow more calls?
No. The limits belong to Xero. The job paces the work and records what it could not do so nothing is lost silently.
Will the job fill the gaps in last month?
Not as part of this fixed scope. A past-month backfill is separately agreed and uses the same checkpoint approach.
What if the job also creates duplicates?
That is a separate failure with its own job. The two fit together, and the project that restores a broken sync covers both.
Send an enquiry
Send us
- The size of a busy run, how it is triggered, and the exact error text with names and amounts removed
- Whether the job runs in parallel and how many workers it uses
- What happens today after the job stops partway
- Do not send credentials, bank details, invoices, customer records or confidential code in the first enquiry
Later, once you agree
- Read access to the job code through the agreed route, with secrets held by you
- A Xero demo organisation connected by you for the job
- Your written rule for held orders and who releases them
- 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 “xero-rate-limit-drops-invoices” as the subject.