Splitting a Cost Across Projects by Attribute

Flowtly Editorial Team6 min

One supplier invoice often has to be shared out across many projects — a security contract covering every building on a site, a cleaning invoice covering every tenant of one building. Entering those shares by hand is slow and drifts out of step whenever a tenant moves in or out.

Flowtly can calculate the shares for you from attributes: numeric properties you record once on your assets and projects. The invoice is then divided in proportion to those numbers, and the amounts always add up to the invoice total.

The two drivers

A split is driven by attribute values, not by anything stored on the invoice. Two levels are available.

  • An attribute on assets — recorded on buildings, plots or other properties. It decides how much of the cost each asset carries.
  • An attribute on projects — recorded on the projects you invoice (typically one project per tenant). It decides how the asset's portion is divided between the projects sitting on it.

An attribute belongs to one or the other. The same attribute name can exist twice, once for assets and once for projects, so check which one you are editing before you type a value. See Two attributes with the same name below.

Where the settings live

The attribute definitions are under Attributes. Each definition has a name, a type (use number) and a unit shown next to the value — m2 for areas, % for percentages.

The value on an asset is on the asset itself, under the Attributes tab of a building or plot in Assets.

The value on a project is on the project, under its own Attributes tab in Projects.

Recording a value is the whole configuration — there is no separate mapping screen. An asset or project with no value for the attribute simply does not take part in that split.

Applying a split to an invoice

Open the supplier invoice and expand Categorisation. Above the list of positions you will find the buttons that fill the split for you:

  • Fill by <attribute> — a flat split across projects, in proportion to one project attribute.
  • Fill by <asset attribute> × <project attribute> cascade — the two-stage split described below.
  • Fill by media consumption — a split based on meter readings rather than attributes.
  • Clear all — empties the split so you can start again.

Pressing a button proposes a set of positions with amounts. Nothing is saved until you save the invoice, so you can press a different button, or clear and retry, without consequence.

How the two-stage cascade works

The cascade answers "which building, then which tenant of that building".

  1. The asset's share is its attribute value divided by the sum of that attribute across every asset that carries it.
  2. The tenant's share within that asset is the project's attribute value divided by the sum of the same attribute across the projects booked on that asset.
  3. The final weight is the asset share multiplied by the tenant share, and the invoice's net amount is divided by those weights.

Two details worth knowing, because they explain results that otherwise look wrong:

  • Which tenants take part is decided by the invoice's receipt date. Only projects with an asset booking active on that date are included. A tenant who moved out before the invoice arrived is not in the split, and one who moved in afterwards is not either.
  • Amounts are rounded so the split is exact. The last grosze are handed to the largest fractions, so the positions always total the invoice's net amount rather than falling a grosz short.

A worked example

A site records Ochrona on its buildings as a percentage:

Building Ochrona
Budynek A 23.98 %
Budynek B 23.42 %
Budynek C 34.60 %
Taneczna 18A 5 %
Taneczna 18C 13 %

Those five values total 100, so each building's share is simply its own percentage. A security invoice run through the cascade gives Budynek C 34.60 % of the cost, which is then divided between the tenants of Budynek C in proportion to their Powierzchnia in m².

The values do not have to add up to 100. If they totalled 200, each building would still take its own value divided by 200 — the total only affects readability, not correctness.

Checking that a split is right

After pressing a cascade or fill button, check three things before saving.

  1. The projects listed are the ones you expect. A missing tenant almost always means either no attribute value on that project, or no booking active on the invoice's receipt date.
  2. The percentages look like the shares you know. Each position shows its weight as a percentage next to the amount.
  3. The total matches the invoice. The categorisation panel shows the sum of the project allocation; it should read 100 % and the invoice's net amount.

Once saved, the same figures appear on each project under Project finance › Related costs, where every row shows both the full invoice amount and the share assigned to that project — the quickest way to confirm a project was charged what you intended.

Common problems

Two attributes with the same name. Nothing stops two definitions sharing a name — one bound to assets and one to projects. Only one of them is the one your split uses. If a split ignores values you are sure you entered, open Attributes and confirm you edited the definition that belongs to the right level.

A tenant renting several units in one building. A project booked on more than one asset is counted once, under a single asset, rather than once per unit. Its share is not multiplied by the number of units it rents.

Tenants with no value for the attribute. If none of the projects booked on an asset have a value, that asset's portion is divided equally between them rather than being dropped. An equal split where you expected a proportional one is a sign the values are missing, not that the cost was lost.

Vacant space. Only assets and projects that carry a value take part, so unlet units are outside the calculation and the occupied ones absorb the whole cost between them. If you want vacancy to carry its own share, it needs to exist as a project with an attribute value like any other.

Connection map

Refers toUses upPart ofDerived from
Documented hereDocumented elsewhere
invoice billed to counterparty. invoice taxed by tax-group. cost spends against budget. cost owed to counterparty. bank-transaction reconciled to invoice. contract schedules payment-schedule-line. contract attached to budget. budget covers project. invoice billed from project. project linked to budget. lead becomes counterparty. deal sold to counterparty.billed totaxed byspends againstowed toreconciled toschedulesattached tocoversbilled fromlinked tobecomessold toIInvoice — A sales document issued to a client: line items, dates, tax. It is created, reviewed, previewed and then sent.InvoiceCCounterparty — The other side of a financial document — a client billed, or a supplier owed.CounterpartyTTax group — The tax treatment applied to a line, so rates are set once rather than per document.Tax groupCCost — Money the organisation owes or has spent, tracked against a budget.CostBBudget — The financial envelope an engagement is measured against — what was planned, versus what has actually been spent.BudgetBBank transaction — A movement on a connected bank account. Matching it to an invoice or a cost is what makes the books agree with the bank.Bank transactionCContract — The financial terms of an engagement: a structured set of payment schedule lines, in one direction or the other.ContractPPayment schedule line — One dated amount on a contract, in a direction — money owed to a supplier, or due from a client.Payment schedule linePProject — The core organizational unit for a business initiative, client engagement or internal work. Everything tracked — time, cost, invoicing, profitability — hangs off one.ProjectPProspect — A company you are working but that is not a customer yet. It sits at New, Contacted or Qualified, and everything done to it is logged against it.ProspectDDeal — A sale in progress: a customer, an amount, and the stage it has reached. It cannot exist without a customer, and its stage is never blank.Deal