A transferred system arrives with a running bill. Whether it arrives with a budget is a separate question, decided by a separate process, on a separate calendar — and the two are connected only by whoever noticed.
Six things, six dates
Financial responsibility is not one object. Service usage, invoice payer, internal allocation, budget authority, forecast, and contractual commitment can each change on a different date.
The distinction that matters most is between approved funding and a forecast. A forecast is a number in a plan; approved funding is a commitment with an accountable owner and a defined scope, and only the second pays an invoice. Funding source and timing can also restrict how flexibly money moves.
An accepted technical handover creates none of this. The receiving budget exists because someone requested and obtained it, and that request has its own lead time, its own approver, and its own fiscal calendar — which is frequently a different calendar from the sending organisation’s.
The delay case is the one to plan
Work the arithmetic. Take an April-to-March fiscal year, 3,000 a month of operating cost, and responsibility transferring on 1 January. January through March needs 9,000 from the recipient.
Slip the transfer to 1 April, and those three months still cost 9,000. The money has not gone away; it has moved to whoever holds the interim arrangement. Add a separately specified 2,000 extension-support fee and the forecast is 11,000.
The transfer date changes the allocation. Only the extra support changes the total. And unused funding does not automatically carry forward, nor does a recipient have to absorb an unapproved delay — both are matters for the actual policy.
So the funding record settles six things before handover: which fiscal calendars and cutoffs apply, which costs are in scope, who pays externally and who holds budget authority before and after, what funding is approved as against merely forecast, who covers dual running and transition assistance if it slips, and who can adjust funding, cut scope, delay, or stop the service.
Reconciling the receiving budget
The reconciliation lists the operating scope and period, the named budget owner, and the approval evidence — recurring infrastructure and model usage, shared services, support, evaluation, staff time, and lifecycle work, with one-time transition costs separated from recurring ones.
Then each cost maps to who receives the invoice or internal charge, who approves it, which cost centre carries it, and when responsibility changes. Existing commitments and their renewal or cancellation dates come from the agreements themselves: a technical account transfer does not establish that a contract can be assigned.
The gap this surfaces is arithmetic and unavoidable. An annual allocation of 12,000, against a flat forecast of 900 a month plus a one-time 2,400 transition cost, totals 13,200 and leaves 1,200 unfunded — before tax, growth, or anything not on the list. Relabelling the cost centre does not close it. The owner revises the scope, the forecast, or the funding.
Showback, chargeback, and the allocation assumption
Showback exposes an attributed cost view to a recipient. Chargeback implements a finance-authorised allocation into official accounting budgets. Chargeback is not universally required and is not a more advanced stage, and neither establishes that the service is worth its cost.
Shared costs need an allocation choice — fixed or proportional splits, a proxy metric, or explicit central funding — and the driver is chosen because it suits the decision. A transaction-count split is an assumption that transactions consume equal resources, which is a claim about the workload rather than a neutral default.
Two bookkeeping rules keep it honest. The pool reconciles to invoices or the chosen cost basis with unallocated items shown, and allocation weights sum to the portion actually allocated with the central remainder retained. Managerial views and ledger postings stay connected without the same cost appearing twice as organisational expense.
The threshold that invites the wrong fix
Unfunded run cost creates pressure to split it, and there is a specific rule about that.
Federal policy prohibits breaking down an aggregated requirement merely to obtain simplified procedures or to avoid requirements above the applicable micro-purchase threshold. Elsewhere, whole-life proposal cost — running from initiation through operation and decommissioning — is the basis for assessing against a delegated limit, alongside non-price approval triggers.
Four orders of 15,000 for an already agreed inseparable deliverable total 60,000, and recording each alone conceals the amount that matters. A 15,000 investigation creating no commitment to further work is a different case: its possible follow-on should be visible, and whether aggregation is required depends on the actual policy.
Near-threshold amounts and year-end timing are prompts for inquiry rather than findings. Staged learning with a real stop decision is legitimate, and distinguishing it from concealment requires the scope, the dependencies, and the chronology.
The rule
What stays fixed is that funding is approved by an authority on a calendar, and neither the authority nor the calendar belongs to the delivery team. What changes is the transfer date, and every slip reallocates real money that someone has already committed to spend.
Not to be confused with
Accounting recognition. Cash payment dates and accounting periods differ, and changing a showback or chargeback field is reconciled against approved allocations and obligations rather than treated as an accounting decision.
Evidence of gaming. No prevalence of threshold avoidance is established, and no organisation’s conduct is alleged. The diagnostic reconstructs the decision record and routes the real cost boundary to the applicable authority.