Budgeting
You know why a fully refunded tax is not a cost, what the refund percentage really controls, and when tax becomes real money in the budget.
Tax behaves unlike everything else in the budget, and that is what makes it confusing: **most of the time it is not a cost at all.**
A production pays VAT on what it buys and normally reclaims it. Money goes out and comes back. It affects *when* you need cash, not *what the production costs*.
That is what **Refund** controls, and why it is 100% in most countries. At a full refund:
- the tax is **not added to any total**; - it still matters, because the cash leaves before it returns; - nothing is collected anywhere.
So an account with tax applied and a 100% refund looks unchanged. That is correct, not a missing feature.
Below 100%, the part you do **not** get back is money the production has genuinely spent. That part — and only that part — is collected into the account named in **Collect Remainder In Account**.
| Refund | What the budget does | | ---------- | ------------------------------------------------ | | 100% | nothing is collected; tax is a timing matter | | Below 100% | the unrefunded share is collected as a real cost |
The demo budget refunds nothing, which is why its VAT collects in full. At a 100% refund that column would stay empty.
This is why the field is called *Collect **Remainder** In Account* rather than *Collect In Budget Account* like the fringe fields: it collects a shortfall, not the whole charge — see [how collect-in accounts work](/kb/article/how-collect-in-accounts-work).
**Reporting Interval** says how often the tax is settled — monthly, quarterly, and so on. It changes nothing about the amount. It exists because the cash flow needs to know when the money moves, which is the same reason a fully refunded tax is worth recording at all.
An account carries one tax, and choosing a second replaces the first. A line subject to two different rates is two lines, and splitting it is the accurate way to budget it.
Subaccounts are the exception: unlike fringes and extra costs, **tax can be set per subaccount**, so an engagement whose phases are taxed differently does not need splitting.
Accounts and subaccounts can. Markups cannot, and the reason is worth knowing because the asymmetry looks arbitrary otherwise.
A tax refunded below 100% collects its remainder into an account. That account counts toward net production costs — and a markup is normally calculated *on* net production costs. A tax on a markup would therefore feed the very total the markup is derived from, and the calculation would chase itself.
It is the same circularity that stops `NPC` being used inside an account expression and `GT` being used anywhere in a budget — see [use budget totals as a markup base](/kb/article/use-budget-totals-as-a-markup-base).
The reverse direction is fine, and is why the option exists: a tax remainder can be **collected into** a markup, because a markup sits outside net production costs. Collecting there keeps the remainder clear of the totals other markups are calculated from.
The common case is the self-employed. Freelancers and companies invoicing for their work carry no wage fringes but are usually subject to VAT — so the Taxes panel is where their on-cost belongs, and putting fringes there instead inflates the budget with contributions nobody will pay — see [budget personnel and wage earners](/kb/article/budget-personnel-and-wage-earners).
Markdown