How the Tax Summary Report Calculates What You Owe

The tax summary report answers one specific question: for each month, how much taxable revenue did you invoice, and how much tax did you collect on it? It's built by grouping every eligible invoice by the month of its invoice date, then adding up two numbers per month — taxable revenue and tax collected — separately for each currency you bill in. The logic behind which invoices count, how the split between revenue and tax is derived, and why the report is organized by invoice date rather than payment date all shape what the final numbers mean, and it's worth understanding before you hand a printout to an accountant as a stand-in for a real tax filing.

Which Invoices Are Counted

Two categories of invoice are excluded before anything is totaled. Estimates are skipped outright — the report only considers documents of type "invoice," since an estimate hasn't generated any actual revenue or tax liability yet, no matter how likely it is to be accepted. Draft and cancelled invoices are also excluded, on the reasoning that a draft hasn't been sent to anyone and represents no obligation yet, and a cancelled invoice was voided precisely because the transaction it described didn't happen. Every other status — sent, partially paid, overdue, paid — is included, which is a meaningful design choice: the report counts invoiced tax, not collected tax. An invoice that was sent three weeks ago and still hasn't been paid contributes its full tax amount to the relevant month's total, exactly the same as one that was paid the same day it was sent.

Why It's Grouped by Invoice Date, Not Payment Date

The month used for grouping is taken from the invoice's own date field — specifically, the year and month portion of it — not from when a payment was recorded against the invoice, and not from when the invoice was created in the system if that happens to differ from its stated invoice date. This matters most for invoices with long payment terms: a Net 60 invoice dated in March that finally gets paid in May still shows up in March's totals, not May's. For most accrual-style bookkeeping this is the expected behavior, but if you or your accountant are thinking in cash-basis terms — counting revenue when money actually lands — this report will not match that view, and there's currently no toggle to switch the grouping basis. Any invoice whose date field isn't a clean four-digit-year, two-digit-month value is silently skipped from the report rather than causing an error, which in practice only affects malformed or legacy data.

How Taxable Revenue Is Derived, Not Stored

The report doesn't pull a separately-stored "taxable revenue" figure from each invoice, because no such field exists. Instead it's derived on the fly as the invoice's total minus its tax amount, floored at zero. This is the inverse of how the total itself was originally built — tax was calculated by applying the tax rate to the post-discount subtotal, then added to produce the total — so subtracting the tax amount back out reconstructs the taxable base. The floor at zero exists as a defensive measure against any invoice where a data inconsistency might otherwise produce a negative figure; in ordinary use, since tax is a percentage of a non-negative base, this floor essentially never triggers.

Per-Currency Grouping Inside Each Month

Within a given month, if you've invoiced clients in more than one currency, the report doesn't combine them into a single blended number. Each month's data is further split by currency — you'll see, for instance, a March row for USD invoices and a separate March row for EUR invoices, each with its own taxable revenue, tax collected, and invoice count. As with the other financial reports in the product, there's no exchange-rate conversion anywhere in this calculation; currencies are kept strictly separate rather than estimated into one number using a rate that would already be stale by the time you read the report.

Invoice Count as a Sanity Check

Each row also carries a count of how many invoices contributed to it, which is useful less as a headline metric and more as a way to sanity-check the totals — if a month's tax figure looks unexpectedly high or low, the invoice count tells you quickly whether that's because of an unusually large or small number of invoices that month, versus one outlier invoice skewing an otherwise-normal count. It's a small addition, but it turns the report from a pair of raw numbers into something you can actually audit at a glance.

Sorting and Export

Rows are sorted with the most recent month first, and within a tied month, alphabetically by currency code, so a multi-currency workspace still gets a stable, predictable ordering rather than one that shuffles between report loads. Like the aging report, this one is available as a CSV download with the same period, currency, invoice count, taxable revenue, and tax-collected columns as the JSON view — useful for pasting directly into a spreadsheet a bookkeeper is already maintaining, without needing to re-derive any of the numbers by hand.

What This Report Is Not

It's worth being precise about the report's limits, because tax reporting is one of the few places where an incorrect assumption has real consequences. This report reflects tax as calculated on your invoices using whatever tax rate you entered when you built each one — it has no awareness of jurisdiction-specific tax rules, nexus thresholds, exemptions, or filing requirements, and it doesn't distinguish between different types of tax if you operate somewhere with multiple applicable tax categories on a single line item. It's a summary of what you charged and calculated inside your own invoices, not a substitute for a jurisdiction-aware tax engine or professional tax advice. Treat it as the fast, accurate answer to "how much tax did I put on invoices this month," and hand the underlying question of "is that the right amount, and where does it need to be filed" to whoever handles your actual tax compliance.

How This Connects to Discount-Before-Tax Calculations

The tax amount that feeds into this report on each invoice was itself calculated on the post-discount subtotal, not the original one — discounts are applied before tax is calculated anywhere in the product, which means a discounted invoice's tax figure already reflects that reduced base by the time it reaches this report. You don't need to do any extra adjustment for discounted invoices when reading the tax summary; whatever tax amount is stored on the invoice already accounts for any discount that was applied to it, and the report simply totals those already-correct per-invoice figures up by month and currency. This is worth knowing specifically because it means the "taxable revenue" figure this report shows you — total minus tax — is also already net of discounts, not a pre-discount subtotal you'd need to reconcile against separately.

A Worked Example Across Two Months

Say a workspace sends three invoices in March: one for $1,000 with $80 tax, one for $500 with $40 tax, and one estimate for $2,000 that never converts to an invoice that month. The estimate is excluded entirely, so March's tax summary shows two invoices, $1,380 in taxable revenue ($920 plus $460, derived by subtracting each invoice's tax from its total), and $120 in tax collected. If one of those March invoices doesn't actually get paid until April, it still counts entirely in March's totals, not April's — April's row will only reflect invoices actually dated in April, regardless of what got paid that month. This is the clearest illustration of why the report is organized by invoice date rather than payment date: it's answering "what did I bill and what tax did that generate," not "what tax-bearing revenue actually landed in my account this month."

Zero-Tax Invoices Still Count

Not every invoice necessarily has tax applied — some services or jurisdictions are tax-exempt, and plenty of workspaces simply don't charge tax at all. Those invoices aren't excluded from the tax summary the way drafts and cancelled invoices are; they're included with a tax figure of zero, which means they still contribute their full amount to that month's taxable revenue and still count toward the invoice count, they just add nothing to the tax-collected column. This matters if you're eyeballing the report and notice a month where the invoice count looks high relative to the tax collected — that's not necessarily a data problem, it can simply mean a chunk of that month's invoices were tax-exempt or untaxed by design, and the report is correctly reflecting that rather than silently dropping those invoices from the count.