Allocation rounding
This page is the answer to "why did this building get one cent more than that one". It is short, and it is exact, because it is the page you forward to an owner or an auditor who has queried a penny.
Everything is whole cents
A split is computed and stored in integer cents. Not dollars, not floats, not percentages that get multiplied back out. The percentage on screen is a description of the split; the cents are the split.
That is why a percentage is shown to four decimal places — 33.3333% — while the money is shown to two. Four decimals because a three-way split is the common case and 33.33 three times is not a hundred. The percentage is display precision. It is never used to re-derive the money.
The rule: largest remainder
Splitting $1,000.00 three ways gives each share $333.3333…, which is not a number of cents.
InletAP uses the largest remainder method, also called Hamilton's method:
- Work out each row's exact share.
- Give every row its whole cents.
- Hand out the leftover cents one at a time, largest fractional part first.
Three shares of $1,000.00:
| Row | Exact share | Whole cents | Leftover cent | Final |
|---|---|---|---|---|
| 1 | $333.3333… | $333.33 | +$0.01 | $333.34 |
| 2 | $333.3333… | $333.33 | — | $333.33 |
| 3 | $333.3333… | $333.33 | — | $333.33 |
| $999.99 | $0.01 | $1,000.00 |
The sum is $1,000.00. It is never $999.99. There is always exactly one cent to hand out here, never a fraction of one left over, because the leftover is by construction a whole number of cents smaller than the number of rows.
Which row takes the extra cent
Whichever row has the largest fractional part. When fractional parts tie, the larger weight wins; when weights also tie, the earlier row in the split wins.
That is why row 1 takes the cent in the table above: three identical thirds tie on everything, so the tie falls to the first row.
A worked case where the fractions do not tie — $9,600.00 split by unit count across 48, 40 and 30 units:
| Property | Units | Exact share | Whole cents | Extra cent | Final |
|---|---|---|---|---|---|
| Maple Court | 48 | $3,905.0847… | $3,905.08 | — | $3,905.08 |
| Elm Terrace | 40 | $3,254.2372… | $3,254.23 | +$0.01 | $3,254.24 |
| Oak Ridge | 30 | $2,440.6779… | $2,440.67 | +$0.01 | $2,440.68 |
| Total | 118 | $9,599.98 | $0.02 | $9,600.00 |
Two cents were left over. Oak Ridge's exact share sits furthest past a whole cent (0.7966 of a cent), Elm Terrace's is next (0.7288), and Maple Court's is last (0.4746) — so Oak Ridge and Elm Terrace took one cent each.
The rejected alternative was simpler: round everything down and dump the whole remainder onto one row. It is visibly unfair on a bill that recurs monthly, because the same building carries the entire rounding error twelve times a year. Largest remainder spreads it, and does so deterministically.
The extra cent is recorded, not recomputed
Each allocation stores whether it was the row that took a leftover cent.
Storing it rather than recalculating it on demand is deliberate. The rule is deterministic — the same inputs always produce the same output, including the tie breaks — so recomputing would agree, until the day somebody edits a unit count and it quietly does not. A partner asking about a penny gets the recorded answer for the split as it was made, together with the figures it was made from, out of the audit trail.
A split balances to the cent, not to within a cent
A split must sum to its line exactly. Zero drift. Not "within a cent".
The distinction matters more than it sounds. Elsewhere in the export path there is a one-cent tolerance for line items read off a PDF, and that is the right tolerance there: a vendor's own printed subtotal can be a rounding away from its own lines, and refusing the invoice over it would help nobody.
It is the wrong tolerance here. Twelve allocations each half a cent out is six cents of real money, and a tolerance wide enough to absorb six cents is wide enough to absorb a genuine mis-coding. So the split is checked at zero, and nothing saves while the Remaining chip is non-zero.
Typed amounts are never re-rounded
When you split by dollars, you have stated the answer. Those cents are stored as typed and no rounding rule touches them.
The consequence is that a typed split can be out of balance in a way a computed one cannot, which is what the Remaining chip is for. Press ⌘+⏎ to drop the difference onto the row that should carry it.
Credit notes
A credit note is split by allocating the amount as a positive figure and putting the sign back afterwards, so a credit of $1,000.00 across three properties is -$333.34 / -$333.33 / -$333.33. Doing it the other way round would hand the leftover cent to the smallest share instead of the largest, because rounding a negative number down moves it away from zero. The row that takes the extra cent on an invoice is the row that takes it on a credit.
Every slice of a credit must be negative, just as every slice of an invoice must be positive. A single row pointing the wrong way is refused, because a -400.00 among five positive rows still sums to the right total while paying one building to be billed.
Where to go next
- Splitting an invoice — where the Remaining chip lives.
- Allocation templates — why a re-applied template lands on the same cents.
- Exports reference — what the balanced split becomes in your ledger.
- Audit trail — reading a split back months later.