Browse the knowledge base

Period-filtered bulk export — picking the right date range

Bulk export defaults to filtering by invoice date (matches tax-return scope — the invoice belongs to the period of the underlying transaction). Toggle to upload date if you want everything that arrived in a period regardless of invoice date (useful for 'what came in last month?' reviews). Cross-period invoices need attention — see edge cases.

When this article is for you

You're about to run a bulk export for one or more clients and want to know what the date filter actually does. Specifically: invoice-date vs upload-date — which to pick and why. This article walks through both semantics, the period-picker options, and the edge cases where the difference bites (backdated invoices, late-arrival, cross-period uploads).

For the broader bulk-export flow (selecting clients, ZIP structure, formats), see bulk export as a tax advisor. For the underlying review-queue context, see the review queue explained. For multi-currency conversions inside exports, see language handling in exports.

Invoice date vs upload date — the difference

The single most important toggle in the export-period picker.

A worked example: an invoice with printed date = 2026-03-15, uploaded to TaxItEasy = 2026-05-08:

Filter Which period does this invoice belong to?
Invoice date (default) March 2026 / Q1 2026
Upload date May 2026 / Q2 2026

For tax returns (VAT filings, year-end exports, OSS submissions), the invoice belongs to the period of the underlying transaction — i.e. invoice date. The tax authority cares when the economic event happened, not when the administrative paperwork made it to your bookkeeping software. Default is invoice date for this reason.

For "what did the client send me last month?" reviews — workload tracking, communication audits, advisor-side throughput analysis — upload date is the right filter. You're asking about administrative flow, not about tax periods.

The toggle is at the top of the export-period picker, default invoice date. Single click switches.

Common period choices

The picker offers five preset options plus custom:

Previous calendar year

Jan 1 to Dec 31 of last year. Most common for year-end exports + annual VAT reconciliation.

Current calendar year-to-date

Jan 1 of this year to today. Useful for mid-year reviews, interim financial statements, "show me how the books look halfway through" snapshots.

Previous quarter (Q1 / Q2 / Q3 / Q4)

Tax-return-cycle-aligned for clients on quarterly VAT. The picker auto-detects the most-recently-completed quarter and labels it ("Q1 2026 (Jan 1 – Mar 31)").

For German clients running quarterly VAT (Vorsteueranmeldung), the standard quarters align with the BMF filing deadlines. For French clients on the régime simplifié (annual VAT with two interim payments), quarterly might not be the natural period — see custom range.

Previous month

For clients on monthly VAT cycle (most common in Germany for first-year businesses or those over the threshold; standard in most other EU countries). Picker labels with the actual month ("April 2026").

Custom date range

Start date + end date. Useful for:

  • Calendar-year-misaligned fiscal years (e.g. UK clients on April-to-March fiscal year)
  • Specific event windows (e.g. "all invoices from the trade-show period")
  • 90-day rolling exports for monitoring

The custom picker validates dates and won't let you pick a range that crosses 24 months (a soft sanity-check; for genuinely longer ranges, write to support).

Per-country fiscal-period conventions

The picker tries to be helpful with EU-international clients. A few cases worth knowing:

  • Germany: standard calendar year + quarterly VAT (Vorsteueranmeldung). Year-end deadline May 31 of the following year.
  • France: standard calendar year + monthly VAT for most régimes. Annual filing.
  • Italy: standard calendar year + quarterly OR monthly VAT (depending on turnover threshold). Filings due by the 16th of the month following.
  • Spain: standard calendar year + quarterly VAT (modelo 303). Filings due by the 20th of the month following the quarter.
  • Poland: standard calendar year + monthly VAT (JPK_VAT). Filings due by the 25th of the month following.
  • Cyprus: standard calendar year + quarterly VAT. Filings due by the 10th day of the second month after the quarter.

The picker doesn't enforce these — you can pick any period for any client. The presets just match the most common patterns.

Combined with client selection

When you bulk-export across multiple clients, the period filter is applied uniformly to every selected client. You can't mix "Client A's Q1, Client B's Q2" in a single ZIP.

For mixed periods, run multiple bulk exports back-to-back. The download filenames include the period in the name (bulk-export-2026-Q1-clients-001.zip etc.) so you can sort the multiple ZIPs cleanly.

For clients on different fiscal years (UK Apr-Mar vs DE Jan-Dec), you'd similarly need separate exports — the picker is one period at a time.

What's in the export — period-aware fields

Every exported invoice JSON includes both:

  • invoice_date — the date printed on the invoice
  • uploaded_at — the timestamp the invoice arrived in TaxItEasy

So downstream of the export, you (or your accounting tool) can re-filter by either field if needed. The export filter just selects which invoices land in the JSON; the JSON itself preserves both dates.

The bulk-export ZIP also includes a README.txt at the top level stating which date semantics you used ("Period filter applied: invoice date, Q1 2026 (2026-01-01 to 2026-03-31)") so the receiving accountant / colleague / archive system knows the convention.

Edge cases

My Q1 export shows fewer invoices than the client's app shows for Q1. Almost certainly: invoice-date vs upload-date confusion. Some Q1 invoices were uploaded in April (Q2). They appear in your "by invoice date" export under Q1 (correct) but you might be comparing against a client-side view that uses upload date by default, which shows them under Q2 there. Both views are correct given their respective semantics; the bulk-export is the authoritative tax-period view.

Client uploaded a backdated invoice (December date) in February. Shows up in your December export when filtering by invoice date. If you already submitted the December VAT return at the original Jan-31 deadline, you may need to file an amendment for that period. This is a real workflow risk — talk to the client about pace. Some advisors set a per-client "no more late uploads after deadline" policy and refuse to amend (the late invoice becomes part of next period).

Period includes today's date — should I wait? Up to you. Some advisors prefer to wait until the period is fully closed (e.g. don't run a February export on Feb 28 — wait a few days for late-arrival invoices to settle, then run on Mar 3 or 4). The export is a snapshot, not a stream. If you re-run the export on Mar 5, late-arrival invoices that came in Mar 1–4 with February invoice-dates are now included.

I want a "last 90 days" rolling export. Use the custom date range with end-date = today and start-date = today minus 90 days. The picker has a quick-action button "Last 90 days" that does this for you (rolling = relative-to-today, not anchored to calendar quarters).

Client uploaded a multi-year batch (5 years of historical invoices) in one weekend. All uploads have the same upload-date (the weekend), but the invoice-dates span 5 years. By-invoice-date filter spreads them across the right periods (correct). By-upload-date filter shows them all in the upload-date period (also correct, just different semantic). For year-end this matters: the client's "I uploaded 5 years of old invoices in May 2026" should appear in each year's tax records by invoice date, not all dumped in 2026.

The fiscal year doesn't align with the calendar year. Use custom range. UK clients on April-to-March, Australian clients on July-to-June, etc. The custom picker handles any range; the receipt-side accounting tool needs to know the convention via the README.txt or via your manual labelling.

Period spans a VAT-rate change. Germany's COVID-era 16% VAT (Jul–Dec 2020) is the classic example. Invoices in the export span the rate change; the JSON preserves the per-invoice rate as extracted (not retroactively normalised). Your accounting tool needs to handle the rate transition correctly; the export is faithful to what was on each invoice.

Backdated correction invoice. Sometimes a supplier reissues an invoice with a corrected amount + an old printed date. The corrected version arrives in your queue with the original invoice date. Bulk export will include it in the original period (by invoice date). If the original was already submitted with the wrong amount, this is the trigger for a VAT-amendment workflow on your client's side.

I need to export only "approved" invoices. Combine the period filter with the status filter (in the bulk-export picker, untick Include pending). Default is "all" (approved + pending); for clean year-end snapshots, "approved only" is the right setting.

Multiple advisors at the same firm — can we run different bulk-exports for the same client at the same time? Yes, each advisor's bulk-export is independent. The system doesn't lock — you can both run "Client A, Q1, all clients" and get two identical ZIPs. The cost is two embedding-API calls + two ZIP-builds, but it works.

Related

Didn't answer your question? Write to [email protected] · the AI chat in the bottom-right corner answers most common questions.