Charging for a movement means knowing the aircraft's weight, the route it flew, how long it sat on the ground, and which tariff line applies, then being able to show your working when an operator queries the invoice six months later. Firelinkx scopes systems where the calculation is explainable and the record behind it has been validated by two people.
The officers entering movements from flight strips, the supervisors validating them, and the finance and management users who need the totals to reconcile and the reports to be defensible.
Movements are typed into a workbook that grew organically, formulas differ between tabs, and the person who understands the sheet is the constraint on the whole month. Nothing in it records who entered a figure or what it was before.
An operator queries an amount and the answer requires reconstructing which weight, which duration, and which rate were used at the time. If rates have changed since, the reconstruction is guesswork.
Without a separation between entry and validation there is no point at which a record becomes official, which means every figure downstream is provisional and every dispute is open.
A turnaround is two legs of one visit. When they are recorded independently, parking duration is guessed, movements are double-counted, and the statistics disagree with the charges built from them.
Every charge traces back to a validated movement and a rate that was in force on the day. The chain is the point: change any link and the system can still tell you what the figure was and why.
Aircraft types with their weight and dimensions, registrations mapped to types, operators and their billing accounts, and locations with their codes and aliases. The charge is only as good as these.
Category, direction, and outcome recorded separately, with the fields each category actually requires. Officers work close enough to the flight-strip layout that the change is learnable in a shift.
Arrival and departure are joined into one visit, so parking duration is derived from the aircraft's last known state at that aerodrome instead of being estimated.
Repeated entries are flagged at the point of entry, and a combined flight number that will not split cleanly is raised for an officer to confirm, never silently accepted.
A movement becomes official only when someone other than the person who entered it approves it. That transition is the boundary between a draft and a figure the department will stand behind.
The charge is composed from the published tariff, with the parameters that produced it recorded alongside the result. A rate change tomorrow does not alter what was charged today.
Structured output that Accounts can raise invoices from, without the system pretending to be the accounting package or holding the receivable.
Movements by aircraft, operator, route, category, and period, from a daily count to an annual return, built from the validated records, not assembled by hand.
Each of these is a record with a history, because a charge queried later is a question about what these held at the time.
Separation of duties is the control that makes the output defensible, so it is built into the system and not left to procedure.
These sit on a queue with a name against them. A period that closes over them is a period that will be reopened.
Built from validated records, so a report and an invoice cannot disagree.
The spreadsheet survives because it fits how officers work. A replacement that ignores that gets filled in twice, once properly and once in the old sheet, and the old sheet wins. The first release should feel like the strip layout and take less time than the workbook did.
This is billing-adjacent work with published tariffs behind it, so it is scoped against a written specification rather than estimated, and priced from that document.
Fixed-scope engagement
The charge rules with their test cases, the movement categories and their fields, roles and separation of duties, the audit model, reporting, and acceptance criteria. Procurement-ready, and yours whether or not Firelinkx builds it.
Quoted from the specification
Priced against the agreed document, in staged releases with acceptance at each stage, so the department is never asked to accept the whole system on one day.
Scoped to the system
Hosting, monitoring, backups with tested recovery, patching, and a defined support responsibility for a system a billing cycle depends on.
Every proposal separates the one-time build from the monthly operations that follow it. See full pricing for how both are structured.
Review representative records, current tools, staff responsibilities, handoffs, delays, and exceptions.
Specify records, states, permissions, approvals, integrations, reports, and acceptance checks.
Deliver working stages that staff can test against representative scenarios before the scope expands.
Plan data migration, training, deployment, support responsibilities, and the operational cutover.
Bring a representative job, record, exception, or report. Firelinkx will help define the users, controls, integrations, and first useful release.