Ledger

Each project’s Ledger tab has two sides: what you owe the professionals working on it (Fees), and payment certificates for the contractor's work (Construction). Both move through the same approval chain before anything is marked paid.

Not everyone on a project sees the same amount of this — directors and admins choose who can see each side, and whether they see amounts at all. See Ledger access in the project's Settings tab.

General expenses

General expenses are office costs that do not belong to one project: petty cash, salaries, rent, utilities, equipment, and similar day-to-day spending.

Use the General expenses page for these. Each row has a date, description, category, and amount. BuildFlow groups the rows by month, totals each month, and shows category totals at the top so you can see where the office money went.

This is only a record book. It does not create approval tasks, certificates, or reminders on a project board. Access is controlled from Settings in the workspace's Ledger access panel. Admins can edit it; other people only see it if an admin gives them access.

Team expenses & reimbursements

A claim is money a team member has already spent out of their own pocket for the project or the office — a taxi fare, materials picked up on the way to site, anything like that — and is now asking to be paid back for.

A team member adds one from their own My expenses page: the date, what it was for, the amount, and a photo of the receipt.

Add the receipt photo first and the details fill themselves in — the shop's name, the amount, and the date are read straight off the receipt into the form. Check them before you submit; anything you've already typed is left alone, and if the receipt can't be read you simply fill the form in as usual.

From there, a claim moves along a simple path: Submitted — waiting for someone to look at it; Approved — checked and accepted; Reimbursed — the money has actually been paid back to them. If a claim is turned down instead, it comes back Rejected, with a note saying what to fix, so the person can correct it and send it in again.

Anyone given Edit access to the general expenses book — the top choice in Ledger access — can approve a claim and mark it reimbursed.

Professional fees

Add one fee agreement per professional on the project — architect, QS, structural engineer, contractor, whoever you've agreed a fee with. It doesn't matter which direction the money travels: use an agreement for what the client owes your firm, and equally for what your firm owes a consultant it brought onto the project.

When adding one: Paid to is who receives the money, Paid by is who pays it, Approved by is the role or person who signs off when approval is needed, and Notes is a plain reminder of what the fee covers, like "structural design plus three site visits". Click into Paid to or Paid by and the choices appear right away — roles like Architect or QS, the people on your project, and names you've used before — or just type any name or firm. Naming a role here is only a label on the record; it doesn't give anyone access to the ledger.

Reading the ledger

Each agreement reads like a simple account, with three columns: what it's called, what was Agreed, and what's been Paid. Across the top of the card you'll see the running totals — Agreed − Paid = Due — so you always know what's outstanding at a glance.

Underneath, every fee proposal on the agreement gets its own row, with its milestones or logged events nested underneath it. Click any row to open it and see the full detail — the proposal's paperwork, an event's date, or a payment's approval history.

A payment that's still waiting on someone to approve it shows in the Paid column too, but greyed out with a status chip next to it, rather than in solid black — that's your cue that it's not settled money yet. It isn't added into the Paid total until someone actually approves it all the way through and marks it paid. A payment that was turned down and never resubmitted stays out of the totals altogether.

Grouped and chronological views

Two buttons above the table switch how the rows are arranged:

• Grouped (the default) — every fee proposal sits together with its own milestones or logged events nested underneath it, and payments listed separately below. This is the view for checking one proposal's progress at a time.
• Chronological — everything on the agreement, proposals and payments alike, laid out flat in the order it happened. Reach for this when you want to see the story of the account as it unfolded — reconciling against a bank statement, or walking a client through "here's what happened and when." A milestone that's waiting on a task (see below) takes its place in this list by the date of the task it's waiting on, with a chip naming that task.

Both views always add up to the same totals — switching between them never changes what's Agreed, Paid, or Due, only how the rows are arranged.

Adding a fee proposal or a payment

One button, + Add entry, covers everything you can add to an agreement. It offers a Fee proposal, of two kinds, or a Payment:

• Lump sum — a fixed fee with a payment plan. Give the proposal a title (and a reference like BU-DE-01 if you have one), then add its milestones — an advance on appointment, a payment on completion of the design, and so on. Each milestone has a description, an amount, and says when it falls due (see Payments that wait for a task), and the proposal's total is simply the sum of the amounts. Each milestone becomes its own reminder on the board and can be invoiced and paid on its own.
• Event-based fee — a fee charged each time something happens: a site visit, an inspection, a certification, a meeting, anything that recurs. Set the fee per occurrence once, then log each one as it happens — it counts, and is due, straight away. Billing a site-visit task with Bill this visit adds one of these and logs that occurrence for you; you can also log occurrences by hand on the agreement. Changing the fee charged per occurrence later only applies going forward — it never changes what an occurrence already logged was billed at, so a client's earlier invoices never quietly change under them.
• Payment — starts a payment entry pre-filled with the outstanding amount. You can tie it to a specific milestone so that milestone is marked paid and its board reminder closes once the payment goes through.

Have the fee proposal as a document? Open a lump-sum proposal and use Fill from a proposal document — BuildFlow reads it and fills in the title, reference, and the whole payment plan as a draft. Nothing is saved yet: check it over, fix anything it misread, and only then hit save.

Each milestone you add also drops a reminder onto the project's board, on the stage you pick for the proposal (or the first stage if you don't) — so the team sees an upcoming payment as a task. Open the proposal any time to see its milestones and change which stage their reminders sit on. The reminder itself is just that — a reminder; recording that the money actually moved always happens back here, with a payment entry.

Payments that wait for a task

A payment doesn't always fall due on a date. Often it falls due when a particular piece of work is finished — the design is signed off, the drawings go out.

When you add a milestone to a lump-sum fee proposal, choose After a task instead of On a date, then pick the task it waits for from the project. The milestone shows as Not due until that task is marked done, and turns to Due the moment it is. If someone later reopens the task, the milestone goes back to Not due until it's finished again. A milestone is always one or the other — a date, or a task — never both. One thing to watch: if you leave On a date selected but don't actually pick a date, the payment counts as due straight away, not as waiting for anything.

On the Chronological view, a task-gated milestone takes its place in the list at the date of the task it's waiting on, and carries a chip naming that task — click it to go straight there.

Payment certificates

The Construction side records payment certificates the same way a QS reads one off paper, from the cumulative work done down to what's actually due:

1. Enter the cumulative work done so far, plus any variations and price fluctuations.
2. Enter the retention percentage — held back from the work done.
3. Enter material on site and what percentage of it to release.
4. Enter what's already been certified in previous certificates, plus any interest, retention released, advance recovered, or damages that apply to this one.

BuildFlow works out the amount due as you type, so you can check it against your own numbers before saving. The figure you see while filling this in is a preview only; BuildFlow recalculates the final amount from your entered figures the moment you save, so the certificate always matches what was actually entered. A negative amount is allowed — that's a corrective or credit certificate — but you'll get a heads-up before you save one, so it's never a surprise.

Every line on a certificate, in plain words:

• Work done to date — the cumulative value of construction finished so far, valued against the contract.
• Variations — extra or changed work agreed outside the original contract, added on top.
• Price fluctuations — an allowance for material and labour costs that have moved up or down since the contract was signed.
• Materials on site — the value of materials delivered but not yet built in, released at whatever percentage you and the contractor have agreed.
• Retention — a slice held back from the work done, as security until the project reaches practical completion and later closes out — see Retention.
• Advance recovery — the slice of an earlier advance payment being paid back on this certificate, if one is running — see Advance payments.
• Interest — an amount added when an earlier certificate was paid later than it should have been — see Late payments and damages.
• Liquidated damages — an amount taken off for finishing later than the agreed date — see Late payments and damages.
• Previously certified — everything already paid out on earlier certificates, taken off so this certificate only pays for what's newly due.

Worked example — an interim certificate on a house with a contract sum of LKR 50,000,000, retention set at 10%:

Each row rounds to the nearest cent, and the final amount due is rounded rather than simply cut off — so it always agrees with the already-rounded lines it's built from.

Already have the certificate as a spreadsheet? Upload it to Documents and set its category to Payment certificates — BuildFlow reads the cumulative figures straight off the sheet and creates the pending certificate entry for you, ready for approval, no re-typing. (A certificate as a PDF is just attached; type those in by hand.)

Advance payments

An advance payment is money paid to the contractor upfront, before it's earned by physical work — a mobilisation payment is the usual example. Record one from the Construction side with the amount and, if you've agreed one, a pay-back schedule: a start and finish, given as how much of the work is done.

Once an advance is recorded, every certificate that has something to pay back adds an advance recovery line, and the advance's recovered so far total grows to match — right up until the whole amount is paid back. If you'd rather decide the pay-back amount yourself on each certificate, leave the schedule empty and type it in by hand each time instead.

The pay-back schedule in plain words: a schedule of 20 to 90 means recovery starts once a fifth of the work is done, and the advance is fully paid back by the time nine-tenths of the work is done — spread across each certificate that falls in between, in proportion to how much new work that certificate covers.

Worked example — an advance of LKR 5,000,000 on the same LKR 50,000,000 contract, with a 20-to-90 pay-back schedule (recovery starts at LKR 10,000,000 of work done, finishes at LKR 45,000,000):

Retention

Retention is the slice of each certificate's work held back as security, rather than paid straight to the contractor. It builds up into a retention pot as certificates go through — and that pot has a limit: holding stops once the held-back pot reaches its cap, usually one-twentieth of the contract sum (5%), so retention never keeps growing past what's a fair security deposit for the size of the job.

Worked example — the same LKR 50,000,000 contract, cap set at 5% (LKR 2,500,000):

Practical completion

When the project reaches practical completion — essentially finished and fit to hand over, even if a short snag list remains — tick At practical completion on an interim certificate. BuildFlow gives back half of whatever's sitting in the retention pot at that point, as a retention release line on that certificate.

Worked example — continuing the pot above, standing at LKR 2,500,000: ticking the box at practical completion releases 1,250,000 back to the contractor, leaving 1,250,000 still held.

Final certificate

Set a certificate's type to Final once the project is fully complete and every defect has been made good. BuildFlow gives back whatever's left in the retention pot as a retention release, and marks that this project's construction payments are closed out.

Worked example — continuing the same project: the final certificate returns the remaining 1,250,000, taking the retention pot to 0.

Late payments and damages

Two separate things can show up on a certificate when timing goes wrong:

• Liquidated damages — an amount you charge the contractor for finishing later than the date agreed in the contract, typed in as a lump sum and taken off the certificate. Example: work finishes 10 days late, and the contract's agreed rate is LKR 25,000 a day — you'd type in LKR 250,000 as liquidated damages.
• Interest — an amount added to a certificate when an earlier certificate was paid later than it should have been, to make up for the delay. Example: a LKR 5,000,000 certificate is paid 15 days later than agreed — you'd type in whatever interest you've agreed for that delay, say LKR 45,000, as an interest line on the next certificate.

Both are figures you type in yourself — BuildFlow doesn't work out days-late or interest rates for you, it just adds or takes off whatever you enter and keeps the running total straight.

Bills of quantities

Upload a contractor's bill of quantities (a priced BOQ spreadsheet) to Documents and set its category to Bills of quantities. A new action appears on the document — Import BOQ / Add to ledger — right where a programme shows Add to timeline.

1. BuildFlow reads the spreadsheet and pulls out the sections (the priced bill headings) and every underlying item.
2. You get a review: a headline telling you how many items were found, whether the sums reconcile, and how many rows need a second look — with the flagged rows listed so you can check them.
3. If the sheet has more than one priced column (several bidders side by side), pick which column's prices to use before applying.
4. Hit Apply to ledger and the sections move into the Construction side of the Ledger, with the full item list a click away.

The applied sections give you the contract breakdown to check certificates against. Once a BOQ is applied, you can also ask FlowBot about it — a rate, a quantity, a particular line item — and she answers from the real imported figures (only what she can actually find in your BOQ, never a made-up number). FlowBot only sees the BOQ for people with full access to the project.

The approval chain

Every payment entry — fee or certificate — walks through an approval chain before it's approved. Out of the box that's QS submits → project architect checks → director approves, but it's entirely editable:

• Per project, in that project's Settings tab — add, remove, reorder or reassign steps to whichever roles fit how your office actually signs things off. There's a Revert to default action if you want to drop back to the workspace's usual chain.
• Per office, as a workspace default in the global Settings page (admin) — applies to every project that hasn't set its own override.

Changing a chain takes effect immediately, including for entries already partway through it — if a step you removed was still waiting on someone, that entry moves up to whatever is now the last step in line.

When you set a project's chain, everyone on it is automatically given Edit access to the construction ledger — otherwise they couldn't see or approve the payments they're meant to. If you later drop one of them below Edit in Ledger access, BuildFlow warns you: they'll stay on the chain but won't be able to approve.

Open any entry to see its full timeline: who's approved or sent it back at each step, and any note left with a rejection. Whoever's turn it is can approve or send it back; only the last person in the chain can move an approved entry on to sent to client and then paid.

When it's your turn, BuildFlow tells you — the bell at the top right, and an email if you have those on. Clicking either takes you straight to the payment itself, open and ready to act on.

Assignee, role, or watcher?

Three different words come up around who's involved in a payment, and they're easy to mix up:

• Assignee — for a payment task, this is whoever's turn it currently is in the approval chain right now. They're the one who can approve it, send it back, or move it on; see payment approvals on your board.
• A chain step assigned to a role — means anyone holding that role on the project can act once it's that step's turn (e.g. "project architect" — whoever fills that role today). You can pin a step to one specific person instead, if you'd rather it always route to them by name no matter who holds which role.
• Watcher — someone following the task purely to be notified of activity on it (comments, mentions). Watchers never approve anything and are not the assignee — see Watchers.

Statuses

Removing entries (admins only)

A payment record normally stays put — even a paid one, so the history stays clean. If something was entered by mistake, a firm admin can delete it: a single payment entry (or a recorded paid amount), or a whole fee agreement. Both ask twice before removing anything, and the outstanding total recomputes straight away. Non-admins don't see these buttons.

Payment approvals on your board

Behind every fee amount and every certificate, BuildFlow quietly creates a matching task — so it shows up on your board and in My Tasks just like any other piece of work, instead of living only inside the Ledger.

• Who approves it. Whoever that task is assigned to is who can act on it — approve, send back, or move it forward. You'll always find it under your own tasks, no need to go hunting through the Ledger to know it's your turn.
• Reassigning. Only the project's owner, its director, or an admin can hand a payment task to someone else. That keeps who's responsible for approving money clear and deliberate, rather than something anyone can quietly change.
• My Tasks. Open My Tasks and you'll see a dedicated Payments group alongside your regular work — each one showing the amount involved, so you know what you're approving before you even open it.
• The comment trail. Every step — submitted, approved, sent back, sent to client, paid — leaves a comment on the task automatically, with a link straight back to the entry in the Ledger. Open the task at any point and you've got the full story of what happened and when.

Attachments

Attach the paperwork straight to the entry — the certificate itself (plain or the sealed/signed version once you have it), the bill it's based on, or anything else worth keeping with it. Re-uploading under the same label keeps the earlier version rather than replacing it, so the history stays intact.

Generating an invoice

Open any fee or construction entry and tap Generate invoice to turn its figures into a formatted invoice document — it's attached to the entry as a bill and given its own invoice number (like INV-BU-DE-01), which stays with it and shows on the entry. You'll need an invoice template set up first (an admin adds one under Templates). If there's no invoice template yet and you're not an admin, you'll see a note to ask your app admin to add one. Generating the invoice doesn't change the entry's status; when the payment has been approved and it's ready to go out, use Mark sent to client.