Cost Control
You can settle a cost item, and you know exactly which columns move when you do.
In the item's **Paid** cell, **net** if you are subject to VAT — the same basis as Expected, and the same basis as the budget.
**Pay Date** is when the money actually left. It matters beyond bookkeeping: a cash flow plan built on this set reads payment dates, and an account with a rule pointing at the past and no payment date is what the cash flow module calls an outdated rule.
The item stops counting towards **Expected** and starts counting towards **Paid**. It is never in both.
At the account level:
| Column | What happens | | ------------ | ------------------------------------------------------- | | **Expected** | falls by the item's expected amount | | **Paid** | rises by the amount actually paid | | **Free** | adjusts, since Free is Forecast minus everything booked | | **Forecast** | **does not move** — it is yours, and nothing touches it |
That last row is the important one. Settling an invoice does not revise your forecast, and it should not: what an account will finally cost is a judgement, not a consequence of one payment landing.
Common, and nothing to correct. You expected €4,000, the invoice came at €3,850 — enter 3,850. Expected drops by 4,000, Paid rises by 3,850, and the €150 difference reappears as Free on the account.
That is the module telling you there is €150 of forecast nobody has a plan for. Either something else will use it, or the forecast is €150 too high.
**This usually arrives by import.** Paid amounts and payment dates normally come from the accounting system in bulk rather than being typed — the column tooltips say as much, *usually imported from accounting*. Hand-settling is for the gaps between imports — see [import accounting data](/kb/article/import-accounting-data).
Markdown