Batches and the close
If your business groups transactions before sending them to Xero or QuickBooks, one row on the close checklist — Ledger generation — batches, in Data completeness — is about that grouping. It is also the row most likely to look alarming on the first of the month when nothing is actually wrong. This page explains what a batch is, what the close counts, and why the timing of your close changes the answer.
What a batch is, and what actually reaches your provider
A batch collects documents that share four things — the same transaction type, the same period, the same sales channel and the same currency — and rolls them up into one balanced entry. Accounting → Batches lists them, and each row's Type column carries the rule:
Batching groups documents of the same type, period, channel and currency into one aggregate journal entry.
That one rolled-up entry is what matters. On a batch's own page it is titled Aggregate Journal Summary, described as:
The single balanced journal entry this batch posts to the provider — its member documents' lines rolled up by account.
The documents inside the batch — its member documents — do not travel separately. Open one and its sync state reads Syncs through its summary batch, with the explanation "This entry rolls up into a summary batch and syncs through the batch's aggregate entry, not on its own." One batch, one document at the provider, however many orders went into it.
A batch that has not built its summary yet shows an em dash in the Entry column, with the tooltip:
No aggregate journal entry yet — it is generated when the period closes (or on rebuild).
That is normal for the period you are still in. It is only a problem once the period has ended and the settle window below has run out.
Why the close counts summaries and not members
Every figure the close reports follows the same rule: the summary entry is counted, its member documents are not.
This is not a rounding decision, it is the only way the totals can be right. The member documents and the summary describe the same money. Counting both would double every batched amount in the Income Statement, the Balance Sheet, the Trial Balance and the category totals. So the reports read the summary and skip the members, and Sync Category Reconciliation does the same — which is why its per-category totals tie back to the ledger rather than running ahead of it.
The practical effect when you are reviewing a month: a batched sale appears in the month's statements once, inside its batch's summary, not as a line of its own. If you go looking for an individual order in a report and cannot find it, open Batches and find the batch that swallowed it.
The five batch statuses
Sorting or filtering the Status column on Accounting → Batches groups batches by where they are in that lifecycle. The column's tooltip names all five:
Open accepts members · Dirty needs its aggregate rebuilt · Closing is being pushed to the provider · Posted landed in the provider · Reopened is a posted batch receiving corrections.
| Status | What it means for the close |
|---|---|
| Open | Still accepting documents. Expected for the period you are in; a concern once the period has ended and the settle window has elapsed. |
| Dirty | Its membership changed since the summary was built, so the summary is being rebuilt. A Dirty chip appears with the tooltip "Membership changed since the aggregate entry was built — a rebuild is pending". It clears itself, usually in seconds. |
| Closing | The summary is being pushed to your provider. It has left the queue the close counts. |
| Posted | The summary landed at the provider. Nothing outstanding. |
| Reopened | A change arrived after the summary had already posted. The correction is made by reversing the posted entry and posting a replacement, so history is never rewritten — both entries stay visible in the correction chain. |
Ledger generation — batches counts the batches sitting in Open, Dirty or Reopened whose period has ended. Closing and Posted are past the line and are not counted.
Documents can join a batch at any status, including Posted. A late arrival to a batch that has already reached your provider is handled by the reversal-and-replacement above rather than refused — which is exactly why a month you closed can later show drift. See frozen figures, staleness and drift.
Settle windows: the grace period after a period ends
A batch does not close the instant its period ends. Documents arrive late — a marketplace posts yesterday's orders this morning, an invoice lands a day after its date — and a batch that slammed shut at midnight would push those into the wrong period.
So each batch gets a settle window after its period ends, described on screen as "the grace period for late documents to still join the batch":
| Batch period | Settle window | A June batch is due |
|---|---|---|
| Monthly | 72 hours | the start of July 4 |
| Daily | 24 hours | the start of the second day after the batch's day |
The window is counted from the end of the period, in your business timezone — so a monthly June batch is due at the start of July 4, and a daily June 30 batch at the start of July 2. See month boundaries and timezones for what "your business timezone" means here.
A batch inside its settle window is expected pending work, and it never fails the check. This is why the row can pass and still have something to say: it reads 2 still in settle window in grey, with a tick beside it. "Nothing outstanding yet" is a different statement from "nothing outstanding", and the row makes both of them.
Overdue batches, and what signing off over one costs
Only a batch past its window is overdue, and overdue only warns — the month can still close once you acknowledge the row. On the demo tenant, June's row reads 86 overdue, and after the close it carries Acknowledged at close.
Open an overdue batch and an Overdue chip explains the exposure in full:
This batch should have closed and posted by Jul 4, 2026 — the period ended and the settle window (the grace period for late documents to still join the batch) has since expired. Its figures are in the books as a re-derivable draft, but that draft is not final and has not reached your accounting provider, so any month signed off on it rests on a number that can still move. Use Rebuild, or wait for the scheduled close to run.
That is the honest cost of acknowledging this row. The money is not missing — the summary's figures are already in your statements. What they are not is final, and they have not been pushed anywhere. Sign the month off over an overdue batch and you have signed off a number that a rebuild can still change.
What ends that exposure is the batch closing and posting, and there are two routes to it. Left alone, the hourly sweep takes it — it picks up every batch whose settle window has elapsed. That is worth knowing because it tells you how to read the age of an overdue batch: one overdue by an hour or two is almost certainly on the next sweep, and one overdue by weeks has already survived hundreds of sweeps and is stuck on something else. Forced with Rebuild on the batch page, the close happens now — at the cost of a confirmation if the batch has already posted, because the rebuild reverses the posted entry and posts a replacement rather than editing it in place.
That difference matters more than the click. Waiting costs you nothing when you close on the 4th or later; rebuilding a posted batch writes two more entries into a month somebody may already be reading. See fix a failing check for the sequence, and frozen figures, staleness and drift for what a late rebuild does to a month you have already signed.
Ledger generation — batches counts every unposted batch whose period ended on or before the month end — including batches from months you closed long ago. That is how a single month's row reaches a figure like 86 overdue. The row's arrow opens Batches filtered to exactly that set, so check the periods there before assuming they all belong to the month in front of you.
Why to close a few days into the month
Put the settle windows and the sync pipeline together and the timing of your close decides how much of the checklist is real work.
Close on the 1st or the 2nd and you are looking at a month whose batches are still legitimately open. Ledger generation — batches reports batches in their settle window, Entries synced reports entries still in flight, and none of it is anything you can fix — it is work that has not come due. You spend the close chasing normal pending work, and if you close anyway you acknowledge a list of items that would have cleared themselves.
Close from the 4th or 5th onward and the picture is honest. Every monthly batch for the closed month is past its 72-hour deadline, the hourly sweep has had time to close and push them, and the sync backlog has had time to drain. Anything still on the checklist at that point is a genuine exception worth your attention: a batch that failed to build, an entry the provider rejected, a real variance.
The checklist and the scheduled close measure lateness with the same rule, so they cannot disagree about whether a batch is late. If the checklist calls a batch overdue, the scheduled close agrees it is due; if the checklist says it is still in its settle window, nothing is going to close it yet however many times you press Re-check.
Next steps
- Close a month — the full run from Start close to Closed.
- What stops a close, and what only needs a tick — why the batches row is a warning and what acknowledging it records.
- How SKU reconciles with Xero and QuickBooks — where batch summaries land in the reconciliation reports.
- See why entries haven't reached your provider — the reason-by-reason breakdown, including entries that sync through a batch.
- The close checks — every row on the checklist, side by side.
- How entries are grouped by channel — the settings that decide what gets batched in the first place.