Loading
Because the accounting system thinks in periods and the job thinks in stages. Retention, variations and applications for payment do not fit a straightforward sales invoice, so they are tracked separately.
The two versions of the job's position diverge, and the one the accounts show is the one nobody uses.
Costs post to the job as they happen: materials from purchase orders, labour from site attendance in Nest, subcontractor bills from purchasing.
Retention is held against the contract, variations are priced and tracked, and the job's position is a ledger figure rather than a parallel record.
It will not produce a programme. Sequencing and progress live in Loop; Books holds what it cost.
It also does not calculate what you should claim — it shows what has been incurred and certified.
Cost to date is real, so the application for payment is built from the record rather than negotiated from memory.
The final account starts from a position both sides have been able to watch.
Products, not integrations. Each one reads the same record, so a join is a permission rather than a sync job with a mapping screen behind it.
Yes, with release dates.
Yes, per the scheme you operate.
Against the plan in Loop, yes.
Half an hour on your own numbers is usually enough to say whether Books is the right place to start.