Splitting an invoice across properties

A landscaper cuts the grass at five of your buildings and sends one invoice. A roofer bills two properties on one page because they were on the same street. This page is about coding that invoice properly — every building charged its own share, to the cent — rather than putting the whole thing on the largest property and fixing it in the ledger later.

The vocabulary is worth fixing first, because the rest of the docs uses it consistently:

• An allocation is one slice of one invoice coded to one property.
• A split is the set of allocations belonging to one printed line, or to the whole document.
• Balanced means the split sums to the line exactly. Zero drift, not within a cent.

What you can split

A split hangs off a printed line item, or off the document as a whole — which is how an invoice with no line items on it, or one where the distribution genuinely applies to the whole bill, is handled. So an invoice with three lines can have one line split five ways, one line coded to a single property, and one line left alone.

That is the shape the work actually takes. A grounds-care line covers the portfolio; a storm cleanup line covers exactly one building; a fuel surcharge covers whichever properties the truck visited. Splitting per line keeps each of those honest instead of averaging them into one distribution that is right on the total and wrong on every line.

An invoice with no allocations behaves exactly as it always has: it carries one property, and the export codes from that property. Nothing about splitting changes an unsplit invoice.

The five ways to split

Open a line, choose a mode, and the grid fills in. Every mode ends at the same place — a set of amounts in whole cents that sums to the line — but they differ in what you have to type.

A sixth path is applying a saved template, which is what you use once the same split has happened twice.

Two behaviors in that table are worth stating plainly.

By amount is yours, not ours. When you type 4,000.00 / 3,200.00 / 2,400.00 you have stated the answer, so InletAP stores those cents and does not re-derive them from a percentage. Every other mode computes the cents from weights and rounds them (see allocation rounding).

A missing figure refuses rather than guesses. If one building has no square footage on its property record, splitting by square footage is refused and the message names the building. It does not treat the missing figure as zero. Zero would allocate nothing to that property and quietly overcharge every other one — the kind of error that survives for years because every column still adds up.

The Remaining chip

A persistent chip sits under the grid: Remaining $0.00 when the split balances, and the shortfall in dollars when it does not.

Nothing saves while it is non-zero. That is a hard rule and it is the point of the feature. The check is for exact reconciliation — zero drift, not "within a cent" — because a split that is allowed to be a cent out per row is a split that can be six cents out across twelve rows, and a tolerance wide enough to absorb that is wide enough to absorb a genuine mis-coding.

Balancing the last cents is one keystroke, not a re-type: put the cursor on the row that should absorb the difference and press ⌘⏎. The whole remainder lands on that row.

Two other rules are enforced when you save:

• Every allocation names a property. A slice with no property is not a coded slice.
• Every allocation points the same way as the invoice. A -400.00 among five positive rows still sums correctly while paying one building to be billed, and it does not look wrong on screen. A credit note is the honest exception: there every slice is negative, and that is allowed.

The keyboard contract

The grid is built for people who key invoices all day, which means it is built for the keyboard. The mouse works; it is just slower.

Two of those have a deliberate edge worth knowing.

Ctrl+D fills a GL code or a property down the column. It refuses to fill an amount down, because copying one building's dollar figure into every row silently unbalances the split — and an unbalanced split cannot be saved, so the fill would only have cost you the retyping. Use Even or ⌘+⏎ instead.

The = prefix understands +, -, *, / and brackets, and nothing else. It is arithmetic, not a formula language: there are no cell references, no functions, and no way to reach anything outside the cell you are typing in.

Undo works on the whole set because a split is saved as a whole set. The invariant being protected — "these rows sum to this line" — is a property of the set, so the set is what gets written, and the set is what gets undone.

"3 properties detected"

When an invoice names properties in its text, a chip appears above the lines: 3 properties detected. Clicking it shows what was found and the words on the invoice that found it.

Two things are looked at. First, a direct match of your property aliases and property codes against the line descriptions and the invoice text — a line that names exactly one property is proposed at 100% to that property. Second, for the messier invoices, a model pass over the extracted text.

A suggestion is a proposal, never an action. Nothing is saved until you accept it, and the evidence — the actual text on the invoice that named the property — is written into the audit trail with the suggestion. An auditor asking "why did Elm Terrace get 33.33% of this bill?" gets the answer from the record rather than from somebody's memory.

Aliases are what make this work. Ten minutes spent giving each building the names your vendors actually write does more for detection than anything else you can configure.

A worked example

GreenLeaf Landscaping, invoice INV-88213, $12,480.00, three lines:

Three buildings are involved: Maple Court, Elm Terrace and Oak Ridge.

Line 1 — the grounds contract, split by percent. The owners agreed 41.6667 / 33.3333 / 25.0000:

Elm Terrace's exact share is $3,199.9968, so it is the row that takes the leftover cent and rounds up to $3,200.00. That is recorded on the row, not recomputed later.

Line 2 — the storm cleanup, not split at all. It was one building's work, so it is coded to Elm Terrace for the full $2,180.00. A line that belongs to one property does not need a split, and giving it one only adds rows for somebody to read.

Line 3 — the fuel surcharge, split evenly. $700.00 three ways does not divide:

$233.33 three times is $699.99. The extra cent goes to Maple Court, and the split totals exactly $700.00.

What each property ends up carrying:

Every column sums to its line and the grand total is the invoice. That is what balanced means here, and it is checked before anything is written.

After the split

The document still carries one primary property — the one with the largest allocation, Elm Terrace in the example above. That is what the inbox column shows, so a split invoice does not become unrecognisable in a list; the full picture is on the document.

Three other things follow from a split, each with its own page:

• Approvals route per property, and one person who covers three buildings gets one task rather than three. See property approvals.
• The export may become more than one bill, if the properties belong to ownership entities with separate QuickBooks companies. You are told before you press Export, never after. See multi-entity QuickBooks.
• The CSV can be written one row per allocation instead of one row per invoice. See the exports reference.

Undoing a split

Clearing the split removes every allocation and returns the invoice to coding from its own property, exactly as an unsplit invoice does. The clearing is recorded in the audit trail with who did it and when; the amounts are not silently redistributed.

Limits

These are guard rails against a pasted spreadsheet rather than accounting limits — 200 allocations is far past any real portfolio split of a single invoice. See plans and limits.

Where to go next

• Allocation templates — save the split you just made and stop making it.
• Allocation rounding — the exact rule for the odd cent, and who takes it.
• Property approvals — who signs which slice.
• Multi-entity QuickBooks — when one invoice becomes two bills.
• Coding invoices — everything else a coded document carries.