Client Statement vs. Accountant Report: What's the Difference

The client statement and the accountant report both pull from the same underlying invoice and expense data, and at first glance produce fairly similar-looking output — a list of invoices, a list of expenses, some totals. But they're built for genuinely different jobs: one is scoped to a single client and meant to be handed to that client directly, and the other is scoped to your entire workspace and meant to be handed to whoever manages your books. Picking the wrong one for a given situation usually still "works" in the sense that you'll get a document, just not the right one.

Scope Is the Core Difference

The client statement is generated for exactly one client at a time — you request it by that client's ID, and everything in the resulting document is filtered down to invoices and expenses belonging to that specific client, matched the same way the aging report matches clients: first by an exact email match, falling back to an exact match on billing details text. Nothing from any other client appears anywhere in a client statement, by construction.

The accountant report has no client filter at all — it pulls every invoice and every expense across the entire workspace, for every client, in one document. It does still break out a per-client subtotal section within that larger report, so you can see each client's total, paid, and unpaid figures side by side — but that's a summary view sitting inside a workspace-wide report, not a substitute for the fully-scoped, single-client document the client statement produces.

What Each One Actually Contains

The client statement shows, for its one client: every invoice with its date, due date, status, total, amount paid, and amount still outstanding; every expense logged against that client, with vendor, category, and amount; and a set of summary buckets — total billed, total paid, total unpaid, total overdue, and total expenses — each split by currency the same way every other report in the product handles multi-currency data. Notably, it does not include a tax breakdown as a distinct summary figure; tax is embedded in each invoice's own total but isn't pulled out and aggregated separately the way it is in the tax summary or accountant report.

The accountant report shows the same categories of data — invoices and expenses — but workspace-wide, and it adds one thing the client statement doesn't: a tax total, aggregated alongside total, paid, and unpaid, as part of its summary buckets. It also adds the per-client breakdown section mentioned above, giving you both the macro workspace view and a client-by-client lens within a single document, which is exactly the shape of thing an accountant needs when reconciling your books for a period rather than answering a single client's billing question.

Who Each Document Is Actually For

The client statement is built to be shared outward — it's the kind of document you'd send directly to a client who's asking "can you send me a summary of everything you've billed me and what I still owe," or that you'd generate proactively at the end of a project or a quarter as a courtesy recap. Its narrow, single-client scope is exactly what makes it appropriate to hand to that client: there's no risk of another client's financial information appearing anywhere in it, because the data was never pulled in the first place.

The accountant report is built to stay internal — it's meant for you or whoever manages your bookkeeping, giving a full workspace view including the tax figures and cross-client totals that a client has no business seeing about your other clients. Sending an accountant report to an actual client would leak your entire client roster's billing data in one document, which is precisely the scenario the client statement's tight scoping exists to prevent.

Both Are Available as CSV, With Different Columns

Each report supports a CSV export in addition to its JSON view, and the column sets reflect the same scope difference. The client statement's CSV mixes invoice and expense rows together with a shared set of columns — type, date, number or vendor, status or category, total, paid, outstanding, currency — since it's meant to read as a single client-specific ledger. The accountant report's CSV follows the same type-mixing pattern but adds a client column and a tax column, since distinguishing between clients and tracking tax per line is exactly the extra context a workspace-wide export needs that a single-client one doesn't.

Neither Report Converts Currencies

Consistent with every other financial report in the product, both of these are currency-grouped, not currency-converted — if a client has been billed in more than one currency, their client statement will show separate totals per currency rather than one blended figure, and the accountant report does the same across the whole workspace. There's no exchange-rate logic anywhere in either report; see the platform's broader design choice on that point if you're wondering why a multi-currency total doesn't collapse into a single number.

A Simple Rule of Thumb

If the question is "what does this one client owe me, and what's their history with me," generate a client statement for that client specifically. If the question is "what does my whole book of business look like right now, including tax and a breakdown by client," generate the accountant report. The two are close enough in structure that it's easy to reach for whichever one you used last out of habit — but the scope difference is exactly the thing that makes one of them safe to hand to a client and the other one very much not.

When You Actually Want the Aging Report Instead

Neither of these two reports is the right tool if what you actually need is a prioritized list of what's overdue, sorted by urgency, across every client at once — that's what the aging report is specifically built for, with its bucketing by days-past-due and its invoice-level sort by how overdue each item is. The accountant report will tell you a client's total unpaid balance, and the client statement will tell you that same client's individual invoice statuses, but neither one sorts your whole outstanding book by collection urgency the way the aging report does. If your actual task right now is "who do I need to chase today," the aging report is faster and more directly useful than either of these two; if your task is "summarize this client's account" or "give my bookkeeper the full picture," reach for the client statement or accountant report respectively.

How Rebilled Expenses Appear in Each

Expenses carry a rebill status — unbilled, rebilled, or non-rebillable — and both the client statement and the accountant report include that status directly on each expense row, alongside whichever invoice group ID the expense was folded into if it's already been rebilled. This is a small but genuinely useful detail on both reports: it means you can see at a glance, without cross-referencing anything else, exactly which expenses on a client's account have already been converted into invoice line items and which are still sitting unbilled and available to be rebilled. On the client statement this is scoped to one client's expenses; on the accountant report it spans every expense in the workspace, giving you a single place to spot unrebilled expenses across your whole client base that might otherwise sit forgotten.

Estimates Are Excluded From Both

Neither report includes estimates in its invoice totals — both are scoped strictly to documents of type "invoice," consistent with how the aging report and tax summary also treat estimates. This is a deliberate, shared convention across every financial report in the product: an estimate represents a proposed transaction that hasn't happened yet, not revenue or a receivable, so including it in a billed-totals report would overstate what a client actually owes or what your workspace has actually invoiced. If you need visibility into outstanding estimates specifically — proposals still awaiting a client's approval — that's a separate concern from either of these two reports, both of which are answering questions about money that's already been formally billed.

It's worth mentioning that this exclusion isn't a limitation unique to these two reports — the tax summary and the aging report apply the exact same estimate-exclusion rule, which means the entire reporting suite treats "invoice" and "estimate" as genuinely distinct document types with no overlap between them for financial-total purposes, even though both live in the same underlying invoice-editing interface and can look nearly identical while you're building them.