G&A Expense Allocation

Architecture

Key specifications

What it does for you

A management or holding entity carries corporate G&A, shared overhead and the postage meter for a group of operating entities and projects, and none of that cost belongs to it. Every month a recurring workbook -- one tab per month, a driver tab and a lookup tab behind it, a stamped accounting date per period -- turns a column of driver counts into a column of percentages, multiplies them by the month's cost pool, and generates the allocation journal entry. The workbook is copied forward every month, which is precisely why it drifts. Four failures hide inside that, and none of them look wrong on the face of the tab. The share column sums to 99.97% and quietly leaves cost behind in the holding entity, or sums past 100.00% and over-relieves it, every month for the rest of the year. The allocated column was rounded recipient by recipient rather than by a largest-remainder split, or was left stale, and no longer ties the pool it divided -- or ties it exactly while two recipients' amounts sit transposed, so the cost landed on the wrong books. The generated entry balances and no longer matches the schedule it was posted from, because a debit was retyped and the credit was moved with it, or an entity was charged and relieved inside the same entry so both sides inflated and nothing actually moved. And a month was never rolled, or was rolled and stamped to the date of the month it was copied from, so a period is absent from the year or posts real cost into the wrong accounting period. None of these are judgment calls. They are equalities -- a share column against 10000 basis points, an allocated column against the pool, an amount against pool times share, a net debit against the re-derived allocation, a postage line against a physical meter reading, an accounting date against the last day of its own month -- which a deterministic control settles better than a spreadsheet inherited by whoever runs the close this year.

The seeded demo runs every control over every allocation file⁷. The CLI generates twenty-four fictional allocation files -- one clean baseline and one carrying each of the twenty-three planted defects -- then runs all twenty-two controls over each. The clean file returns PASS with no flags; every defect file returns REVIEW or FAIL and names the control it tripped along with the reason that control exists.

A share column that still sums to exactly 100.00%⁸. One defect file moves two shares in the opening month against each other by twenty-five basis points. The column still sums to 10000 bps, so the sum control holds and nothing on the tab looks wrong. alc_shares_rederive rebuilds both shares from the driver counts by largest remainder and fails them, proving the share column is a derivation the engine recomputes rather than a constant it reads back.

An entry that balances and does not tie the schedule⁹. Another defect file reduces one recipient's debit and moves the holding entity's credit with it, so the March entry balances to the cent. je_balanced holds. je_ties_allocation rebuilds the allocation from the drivers and the pool, reads the entry net of any offsetting credit on the same recipient, and fails the line -- the schedule and the entry posted from it had parted company.

Functional block diagram

Instruction set

Benchmarks

Control characteristics

• Read-only: allocation files are parsed and never written back, and nothing is posted, filed or paid, so the engine cannot introduce the break it reports.
• Integer cents and whole basis points throughout, compared with exact ==; there is no tolerance band on an allocation, and a cent off the pool is reported as a break.
• An amount that should be integer cents but is not produces an AMOUNT_INVALID finding contained to the one row it was read on, rather than being coerced into the number the engine is meant to audit.
• One allocation kernel: the controls and the generator share gaalloc_engine.allocation, so a finding cannot disagree with the data that produced it.
• Largest remainder everywhere it matters: driver shares sum to exactly 10000 basis points and allocated amounts sum to exactly the pool, so the residual cent lands in exactly one deterministic place rather than being rounded away recipient by recipient.
• Every accounting-date test is made against the period stamped in the file, never the system clock, so the same file returns the same findings in any month it is run.
• Deterministic and byte-stable: same inputs produce the same findings in the same order, with no timestamps or absolute paths in any output.
• Absent evidence is never a passing control; a missing artifact fails completeness rather than letting the controls that read it pass unread, and each family's precondition owns its own gap so a lost row is named once rather than reported three times downstream.

Operating limits

• The engine never posts an entry, files a return, pays a supplier, or writes to a source artifact. It re-derives the allocation and compares it, then stops.¹⁴
• It reads the eight artifacts the allocation workbook emits. It does not connect to a general ledger, an accounts-payable system, a payroll feed or the postage meter itself.¹⁵
• It is about where a shared cost lands, not whether it should have been incurred, and not whether the driver the policy names -- headcount-equivalents, units, doors -- is the right basis for the group. It checks that the basis was applied, not that it was chosen well.¹⁶
• The month-over-month variance band is a review signal read from the file itself, defaulting to 500 basis points; it is not a materiality judgment, and a pool step inside the band is not asserted to be correct.¹⁷
• It takes the driver counts and the meter readings at face value: it confirms the workbook derives from them and reconciles, not that the counts were captured correctly or the meter was read honestly. All shipped data is fictional and the fiscal year is set in a fictional future.¹⁸

See it run

Integration

Distribution: public repository, MIT license.