Multi-project billing

Bill a large development made up of many individual lots as a single community — one consolidated claim and one invoice per run — while still tracking the contract and revenue for each lot separately.

When to use this

Use multi-project billing when you deliver one development as a community of lots — for example a residential estate, a multi-dwelling site, or a staged development — and you want to bill work across many lots in one go rather than claiming each lot separately.

Each lot keeps its own contract and its own stage schedule, so you still see the numbers per lot. What changes is the billing step: instead of claiming each lot on its own, you claim the whole community from a single worksheet.

You then choose what that claim produces — one invoice for the whole community, or one invoice per lot. Both are billed from the same worksheet in the same way; see Choosing how the community is invoiced.

Multi-project billing uses stage billing for the lots — each lot is billed at fixed milestones (Deposit, Base, Frame, Lock-up, Completion, and so on). If you need % complete billing against a schedule of values, use progress claims instead.

Prerequisites

  • Project Financials installed and configured — see Install & configure
  • A development set up, with a plan per design and the lots generated — see Set up a development
  • A head project for the development, with that development selected on it
  • An estimate on each plan, so lot contract values can be calculated — see Create a plan
  • The community's billing stages agreed — the set of milestones and the percentage of each lot billed at each one
  • Permission to create contracts and claims (varies by role)
  • Optional: a phase set on the head project, if you want the community's cost grouped by release — see Phases across a community

You do not need the lot projects to exist yet. Creating them is a step below.

How a community fits together

A multi-project community has three layers:

  • The head project is the development as a whole. It carries the switch that turns on multi-project billing, and it holds the community's single consolidated view.
  • Each lot is a sub-project beneath the head. A lot has its own contract and its own billing stages, so its value and revenue are tracked individually.
  • The community contract is created automatically on the head project. It is the thing you bill against — every approved lot rolls up into it, and it produces the one consolidated claim and invoice.

Behind the community contract sits a single consolidated sales order. Approving a lot adds that lot's stage lines to it, tagged with the lot, the stage and the lot's contract. It's the sales order the claim worksheet reads and the one the consolidated invoice is produced from, so you'll see one order for the whole community rather than one per lot.

Terminology

This page uses the default names — Development, Plan, Lot, Claim. All of these are renameable, so your buttons may read Create Unit Projects or Create Invoice instead. See Customise terminology.

Setting up a community

  1. Open the head project for the development.
  2. Turn on Multi-project billing on the project.
  3. Save. The system creates the community's consolidated contract for you and links it to the head project. At this point the community contract exists but has no value yet — value arrives as you add and approve lots.
  4. Set up the community's billing stages on the head project — the milestones every lot will bill against, with the percentage of each lot's value billed at each one. Percentages must total 100%.

Adding lots to the community

  1. Make sure your development has its plans and lots set up, and that each plan has an estimate — see Set up a development.
  2. On the head project, click Create Lot Projects, tick the lots you want, and tick Create Contracts?. Click Create.
  3. Each selected lot gets its own project, with the plan's estimate copied onto it and its own contract sharing the community's billing stages. You don't set the stages up per lot — they're copied down from the community so every lot bills against the same milestone structure.
  4. Each lot's contract value is calculated from that lot's estimate plus its markup, then spread across the shared stages by their percentages.

You can create lot projects in batches, stage by stage as the site is released, rather than all at once.

A lot in a community bills through the community, so it does not get its own separate Create Proposal or Generate Sales Order step — that's expected. The lot joins the community when you approve it (next).

Approving a lot to join the community

Approving a lot's contract is what joins it to the community.

  1. Open the lot's contract. Because it's part of a community, it shows a single Approve button — unless the community is set to invoice per lot, in which case it shows Generate Sales Order first.
  2. With per-lot invoicing only: click Generate Sales Order. This raises the lot's own sales order, which is what its invoices will be billed from.
  3. Click Approve. The lot joins the community: its stage values roll up into the community contract and its estimate folds into the community's consolidated figures. With the consolidated default, its stage lines are also added to the community's single sales order.
  4. Repeat for each lot as it's ready. Approving more lots adds them to the same community — the community's stage totals are always the sum of every approved lot.

A lot is only marked Approved if the join succeeds, so a lot showing as Approved has definitely joined.

Changing the stages after lots exist

You can edit the community's billing stages at any time, and the change flows down.

Editing a stage on the head project — its percentage, description or order — re-pushes the whole stage template to every lot. Each lot's stage amounts are re-allocated to the new percentages, and for lots already approved the consolidated sales order and its figures update to match.

Stages that have already been claimed or billed are preserved. Re-allocation applies to the stages still ahead of you, so reshaping a schedule mid-project won't disturb what you've already invoiced.

This is the mechanism to use when the community's milestone structure changes — reallocating a percentage between two stages, for instance. Change it once on the head and every lot follows. Don't edit stages lot by lot.

Billing the community

When milestones have been reached across the community, you bill them all from one place.

  1. From the head project, click Create Claim. On a community head this opens the multi-project worksheet rather than the standard single-project claim screen — the head project only offers the one button.
  2. The worksheet shows one row per lot, with a column for each billing stage. Each cell shows the amount for that lot at that stage, and whether it has already been claimed.
  3. Tick the lot/stage cells you want to bill in this run. You can mix and match — for example, Deposit on every lot, plus Frame on the two lots that have reached it. Row totals, stage column totals and the overall total update as you select.
  4. Set the claim Date, and choose Terms — the Due Date is worked out for you from the terms and the claim date. You can override it if you need to.
  5. Click Save.

The system records the claim and marks those lot/stage cells as billed. What it invoices depends on how the community is set up to be invoiced — see Choosing how the community is invoiced below. By default it produces one consolidated invoice for everything you ticked, and the invoice lines carry the lot, the stage and the contract, so revenue stays attributable per lot even though the customer received a single invoice.

The invoices are produced in the background. When you save, you're told the claim has been accepted, and you land on the claim itself — the invoices appear a few moments later, not instantly. The claim shows an Invoice Build Status which reaches Complete once every invoice has been raised, and its notes list the invoices it produced. If it stops part-way it says so and names the reason, keeps any invoices already raised, and can be submitted again without billing anything twice.

Choosing how the community is invoiced

A community can be invoiced in one of two ways. The choice is made on the head project, using the Consolidated Multi-Project Invoicing setting, and it applies to the whole community.

Ticked — one invoice for the community (default)Unticked — one invoice per lot
What a claim producesa single invoice covering every lot you tickedone invoice per lot, made out to that lot
Releasing a lotApproveGenerate Sales Order, then Approve
Best forone bill to the customer per runreporting revenue and profitability per lot using standard reports

Why you'd choose one invoice per lot. Standard revenue and profitability reporting attributes income to the customer named on the invoice itself. If you need each lot's revenue reported individually using standard reports, each lot needs its own invoice.

You still raise one claim either way, across as many lots and stages as you like, and the claim screen looks and works the same. Everything else is unchanged: each lot keeps its own contract and stage schedule, and the community still rolls up its lots' values.

Choose before billing starts

The setting cannot be changed once any part of the community has started billing — the same work would become billable on two different sales orders at once.

If you try, you're told so the moment you change the tick, and the tick goes back to what it was. Nothing is saved. The same change is refused if you make it from a list view rather than the project itself.

Set it when you create the community, before the first contract is approved. To compare the two ways of working, set up two communities rather than switching one back and forth.

Releasing a lot takes one extra click in per-lot mode

With per-lot invoicing each lot raises its own sales order, so you click Generate Sales Order and then Approve. With the consolidated default you only click Approve. The extra step is expected — it isn't a sign that something has gone wrong.

Billing across multiple runs

You bill a community progressively, the same way you'd bill stages over the life of a normal stage-billing job — just across many lots at once.

  • A cell that has already been billed is locked — its selector is removed so the same lot/stage can't be billed twice.
  • In each later run you simply tick the newly reached lot/stage cells and save, producing one more consolidated invoice for that run.
  • You can add and approve a new lot after billing has started. It joins the community and its stages appear as billable cells, without disturbing anything already invoiced.

Reviewing the community's estimates

Each lot keeps its own estimates, and the community contract gathers them. Approving a lot folds that lot's estimates into the community's consolidated collection, so the collection is always the union of every approved lot's estimates — a lot that hasn't been approved yet isn't in it. Editing stays where the estimate lives: you change a lot's numbers on that lot, and the consolidated view reflects it.

Two places show the gathered picture:

  • The community's estimate collection — the consolidated collection on the community contract. Its worksheet groups by lot, then by cost category, then by line, and it is the view that supports phase grouping.
  • Multi-Project Estimate Collection, a button on the head project. A read-only roll-up across the lots, giving the whole development's cost and revenue picture in one place rather than opening each lot in turn. This view groups by lot and does not group by phase.

Phases across a community

A phase is a delivery grouping — the release or block of units a cost belongs to. Because a community is delivered in releases, phases and multi-project billing are usually used together: billing stages say when a lot is billed, phases say which release a lot's cost belongs to. The two are independent, and a community can use both at once. See Using phases on a project for phases generally.

Setting a community up for phases

  1. Create a phase set with the community's releases in it — see Managing phases.
  2. Nominate that set on the head project: tick Use Phases and select the Phase Set. (If the development carries a phase set, the head project takes its configuration from the development and these two fields are locked.)
  3. Lots created from that head inherit its Use Phases setting and Phase Set automatically, so the whole community shares one phase vocabulary.

A lot must use its head project's phase set — a mismatch is refused on save. And once lots exist on a set, the head's set can't be changed until they're moved off it. Both rules, and the way out of the second one, are covered in Using phases on a project.

Putting a batch of lots into a phase

When the head project uses phases, the Create Lot Projects popup gains a Phase field in its header and a Phase column on each lot line. Set the header once to put the whole selection into a release — the point being that ten lots into phase 3 is one choice, not ten. A phase set on an individual line always wins over the header.

Each lot created with a phase gets it in three places: on every estimate line copied from the plan, on the lot project's own Phase field, and — through the shared phase set — in the community's grouping. The lot project's Phase field is what makes "every lot in phase 3" a single search.

How phases group the consolidated collection

On the community's estimate collection worksheet, Phase is the outermost grouping: phase, then lot, then cost category, then lines. So a phase folds up to the total for that release across every lot in it.

A lot sits wholly under one phase. Where all of a lot's estimate lines agree on a phase, the lot appears under that phase with everything beneath it. Where a lot's lines disagree — some on one phase, some on another — the whole lot appears under (No phase) rather than being split across phases. That's deliberate: it makes the inconsistency visible so you can correct it, instead of quietly filing one lot in two places. A lot whose lines carry no phase at all also appears under (No phase).

Grand totals are unaffected by phase grouping — it changes how the rows are arranged, never what they add up to.

What phases don't do on a community

  • The consolidated sales order lines don't carry a phase. They carry the lot, the billing stage and the lot's contract, which is what the consolidated claim needs. Report revenue by phase from the lot projects' own Phase field rather than from the sales order.
  • Consolidated claims and invoices are not phase-aware. You bill by lot and stage, exactly as described above. There is no per-phase claim.
  • The head project's Multi-Project Estimate Collection view doesn't group by phase — use the community's estimate collection worksheet for that.

What success looks like

  • Turning on multi-project billing creates the community contract on the head project.
  • Each lot has its own project and contract sharing the community's billing stages, with a value derived from its estimate plus markup.
  • Approving a lot rolls its stage values into the community; the community's stage totals equal the sum of all approved lots.
  • Sales orders exist for the community: one consolidated order carrying a line per approved lot and stage, or — with per-lot invoicing — one order per lot.
  • The multi-project claim worksheet lists every lot with a column per stage, and all un-billed cells are selectable.
  • Choosing Terms populates the Due Date.
  • Saving a claim tells you it has been accepted, and the claim's Invoice Build Status reaches Complete a few moments later.
  • The claim then shows the invoices it produced — one for the whole selection, or one per lot if the community is set up that way, each made out to its lot — and those cells become locked against re-billing.
  • The community's claimed-to-date updates to match the invoices raised, without anyone running anything.
  • Editing a head stage percentage re-allocates every lot's amounts while leaving already-billed stages alone.

Gotchas

  • Multi-project billing is a stage-billing model. Lots are billed at milestones. If you need % complete against a schedule of values, use progress billing instead.
  • A lot joins the community when it's approved — not before. An unapproved lot won't appear on the consolidated claim worksheet.
  • With the consolidated default, neither the lots nor the community contract get proposal / sales-order buttons. This is intentional. The lots bill through the community, and the community's sales order is built by approving lots rather than generated by hand — so Create Proposal and Generate Sales Order are hidden on both. Their absence isn't a fault. With per-lot invoicing the lots do get Generate Sales Order, because each lot raises its own — see Choosing how the community is invoiced.
  • Claims are prepared in the background. Saving a claim doesn't put the invoices on screen straight away — you're told the claim was accepted, and the invoices follow moments later. Watch the claim's Invoice Build Status reach Complete. A claim that's still building is not a claim that failed.
  • The consolidated invoicing setting can't be changed once billing has started. The refusal is deliberate: the same work would otherwise be billable on two sales orders at once. Decide when you create the community.
  • With per-lot invoicing, the community's own contract stays open and has no sales order. It's the roll-up for the community's values; the billing happens on the lots. Create Variation is raised on the lot whose scope changed, not on the community.
  • Already-billed cells are locked. To reverse a billed lot/stage, raise a credit/adjustment — don't try to un-tick it.
  • Approve the community's lots from the lot contracts, not the head. The head project's community contract is the consolidated roll-up; you drive approvals from each lot.
  • Change stages on the head, not on a lot. Editing the head re-pushes the template to every lot. Editing a single lot's stages puts it out of step with the community, and the next head-side edit will overwrite it.
  • Build each plan's estimate before creating lot projects. The estimate is what sets the lot's contract value. Lots created from an unpriced plan come through with no value to bill — see Create a plan.
  • Lot creation runs in the background beyond a couple of lots. You'll get a "queued" confirmation rather than immediate results — refresh the development to watch the lot projects appear.
  • Give the head project and its lots the same cost centre set. The consolidated estimate collection builds its category structure from the head project's cost centre. If the lots use a different set, none of the lots' categories are recognised — the collection lists the lines with the Category (and Phase) columns blank and no grouping rows at all. Align the head's cost centre with its lots' and the view groups correctly.
  • Set the head project's phase set before you create the lots. Lots take their phase configuration from the head at creation. Turning phases on at the head afterwards doesn't retro-fit the lots that already exist.
  • Copying an estimate into a lot by hand doesn't bring its line phases. Creating lot projects does write the phase you nominated; a manual estimate import doesn't, so re-phase those lines afterwards.
Last Updated: