What the filter actually does
Both the multi-client bulk export and the per-client period export take an optional from / to date range. The range selects invoices by their invoice date — the date printed on the document — never by the date the client uploaded it.
A worked example: an invoice with printed date 2026-03-15, uploaded to TaxItEasy on 2026-05-08:
| Range you set | Is this invoice included? |
|---|---|
| Q1 2026 (Jan 1 – Mar 31) | Yes — its invoice date is in March |
| Q2 2026 (Apr 1 – Jun 30) | No — upload date doesn't matter |
If you set no range at all, the export covers every invoice the client has.
Why invoice date
Tax periods are scoped by when the economic event happened, not when the paperwork reached the bookkeeping system. A VAT return for Q1 needs the invoices dated in Q1 — including the ones that arrived late. Filtering by invoice date makes the export match the filing period directly, with no mental translation.
The flip side: the export is not an "arrivals log". If you want to know what a client sent you last month, use the client's activity in the app, not the export range.
Picking a range
There's no preset picker to memorise — the range is two dates. The common patterns:
- Previous calendar year (Jan 1 – Dec 31) for year-end packages.
- A VAT quarter (e.g. Apr 1 – Jun 30) for quarterly filers.
- A single month for clients on monthly VAT cycles.
- A custom span for fiscal years that don't align with the calendar year — the range is free-form, so an April-to-March year works the same way.
Whatever you pick applies uniformly to every client in the run. Clients on different periods (or different fiscal years) need separate runs — the ZIP name includes the client count, so multiple back-to-back runs stay distinguishable, and your export history records the exact period per client either way.
Late and backdated invoices
The cases where invoice-date semantics matter most:
A Q1 invoice uploaded in April. It's included in your Q1 export — correct for the filing. If you compare invoice counts against a view sorted by upload date, the numbers will differ; both are right, they just answer different questions.
A backdated invoice arrives after you filed. A supplier issues an invoice dated December, and the client uploads it in February — after the December return went out. Your next December-range export will include it, because the export is built from live data at request time, not from a frozen snapshot. If the amount is material, that's the trigger for an amendment conversation with the client. Some advisors set an explicit "no late uploads after the filing deadline" policy per client.
Re-running near period end. The export is a snapshot of the data as it stands. If you export on the 1st and late invoices with in-period dates arrive on the 3rd, a re-run on the 5th picks them up. Many advisors wait a few days after period close before cutting the final export. Pair this with the period checklist so flags and missing receipts are resolved before you export.
A multi-year historical upload. A client uploads five years of old invoices in one weekend. Invoice-date filtering spreads them into the correct years automatically — nothing gets dumped into the current period.
Verifying what a run covered
Every export run — bulk or per-client — is recorded in your export history with the format, the period you set, and the invoice count per client. If a colleague asks "which range did the March package use?", the history answers it; you don't need to re-open the ZIP.
Related
- Bulk export as a tax advisor — the ZIP structure, formats, and 25-client cap
- Period checklist and VAT return prep — closing a period before the final export
- Language handling in exports — multi-locale considerations