Aerospace institute economic management: five modules for rules a general ledger cannot hold

The situation

A research institute inside the Chinese aerospace system manages money in a way that reads like a finance problem and is not one. Its annual operating plan is issued from the top and decomposed down to departments and to individual projects. Its funding arrives from more than one direction: allocation from the parent organisation, and income from contracts signed with outside customers. Its project cycles run for years, and each project touches a large number of contracts. Research funding, technical upgrade funding, contract payments and defence product pricing are all reviewed against the same money at different moments, by different offices, for different reasons.

By the time the platform project started, the institute’s science and technology office and its finance office were spending their days on manual coordination of that. The stated goal was a management system for programme economics. The obvious implementation — install a finance package and configure it — was the option that had already failed, and it failed for a structural reason rather than a software-quality reason.

The call we made

The unit of record is the commitment, not the voucher. General ledger software assumes a cost has one cost centre, one budget line and one period. In this business a single cost item is simultaneously funded from a named source, committed against a contract milestone, scheduled within a technical upgrade plan, and priced under a defence price review file. Four departments describe the same money four ways, and none of the four descriptions is wrong. Any system that forces one of them to be primary will be worked around, and the workaround will live in a spreadsheet.

So we made the annual plan decomposition the spine of the system, and treated the five business modules as five views onto the same commitment graph — budget, research funding, technical upgrade funding, contract ledger, defence product pricing. Sharing one commitment model and one master data set is what makes a cost visible from four directions at once.

The modules ship independently, on purpose. Different institutes in the system buy different subsets: one needs budget and contracts, another needs research funding and price files. That was a commercial constraint and it turned out to be a design constraint worth respecting — five separable modules over one foundation, each usable alone, all of them better together. It is also the reason the platform moved across the defence industrial base rather than staying in one building.

We did not hide the difficult rules behind a generic adjustment field. Carry-over of unspent funding, reconciliation at project close-out, price review archives, plan revision mid-year: each of these is the actual business, and each is modelled explicitly with its own state and its own audit trail. A system that answers “where did this project’s money come from, where did it go, what is left, which contract is still unpaid” in a week has not solved the problem, however correct its ledger is.

Underneath all of this sat a delivery constraint that shaped everything else. The environment is isolated: no internet, no remote access, installation media and data moving in and out under control, no third-party component with unclear provenance, no telemetry. Everything the system needs has to be on the machine, and every version has to be re-installable from controlled media by people who are not us.

What we built

Budget management — compilation, issue down the organisation, mid-year adjustment, and plan-versus-actual review at department and project level.
Research funding — cost collection by project across its life, milestone tracking, close-out and settlement.
Technical upgrade funding — expenditure tied to the upgrade schedule, so progress and spend are read together instead of reconciled afterwards.
Contract ledger — contract register with payment and receipt milestones, template-based agreements, and the link from each contract back to the plan line that funds it.
Defence product pricing — price files and the review archive that supports them, maintained as structured records rather than as documents in a folder.
Income and cost analysis — comparison by project and by cost category, the view that makes the year’s position arguable with numbers.
Platform-level controls — role-based authorisation by office and by unit, audit logging of key operations, and Excel export for the reporting that still has to leave the system on paper.

Result

The institute runs its annual programme economics cycle in the platform: the operating plan is decomposed and tracked where it is issued, funding is collected against projects rather than reconstructed at closing, contracts carry their payment state, and the price review archive is retrievable. Two offices that had been coordinating by hand now review instead of compile.

The five modules have since been taken up elsewhere in the defence industrial base, which for this kind of system is the only adoption metric that means anything — a finance platform for aerospace programmes is either general enough to be reused under the same rules or it is a one-off. And the honest limit: the hardest part of this engagement was never the software. It was establishing, with the customer’s own finance and programme staff, what the correct answer is when four rules disagree — because in this domain the disagreement is the business, and the system has to record a decision rather than an approximation.

Screens from this system are not published. It runs on client infrastructure with client data, so we show it live instead: a short screen-share walkthrough under NDA, on a system we demonstrate rather than a screenshot we sanitised. Ask for it in the first call.

Technology

Stack	B/S management platform · Oracle · Intranet offline deployment · Classified-environment adaptation · Role-based authorisation with audit log · Excel export
Delivery model	Private deployment, air-gapped intranet, source delivered
Client	A research institute in the Chinese aerospace system (name withheld)
Status	Delivered

What we cannot show

Client identity, unit designations, funding volumes, price files and any live programme data are withheld: the work was built and run inside a classified environment, and nothing from that environment is published. The three screens are cropped to structure — plan decomposition, income and cost comparison, contract templates — with programme names, unit names and amounts removed.