FuelCounter™ — Reconcile Every Uplift Against Reality

Live reconciliation ledger

Every ticket, matched line by line

FuelCounter™ lays each captured ticket beside its supplier invoice and the actual flight record. Matches go green and move on; anything that doesn't add up is flagged, surfaced, and held for review — never silently absorbed into your totals.

ReconcilingANC · batch 2026-06-22

1,284 rows96.4% matched46 flagged

Flight	Tail	Airport	Ticket gal	Invoice gal	Schedule	Status
BA286	G-XLEB	SFO	18,420	18,420	on schedule	✓ matched
EI104	EI-EIN	JFK	12,065	12,065	on schedule	✓ matched
DL142	N825DN	ATL	21,900	19,300	on schedule	⚠ volume mismatch
LH418	D-AIXH	IAD	33,180	33,180	on schedule	✓ matched
UA931	N2748U	LHR	27,540	27,540	no flight found	⚠ ghost flight
AF023	F-HPJB	JFK	29,710	29,710	on schedule	✓ matched
BA286	G-XLEB	SFO	18,420	18,420	on schedule	⌥ duplicate ticket
EK202	A6-EOB	JFK	41,260	41,260	on schedule	✓ matched
QR707	A7-BAA	ORD	38,050	38,050	on schedule	⚠ price variance +4.2%
DL410	N511DN	SEA	15,880	15,880	on schedule	✓ matched
VS046	G-VBOW	YVR	31,420	—	on schedule	⌥ no invoice yet
NZ002	ZK-NZH	SFO	44,100	44,100	on schedule	✓ matched

Gates cleared: 5 / 5 46 exceptions queued for operator review · $0 committed to totals until cleared

Illustrative ledger. In production every row keys off a stable identity — airport_date_ticket# — so the same file uploaded twice never double-counts, and every flag is traceable back to its source document.

The validation gates

Five gates. One "no" stops the file.

Each export passes through five sequential checks before a single gallon reaches your dashboard. If a file fails at any gate, every gate upstream rolls back cleanly — no half-written data, no silent drift.

Clean-up & aircraft resolution

Every aircraft is identified

Capture sometimes can't name the aircraft and writes a placeholder — and roughly half a typical export comes through unresolved. FuelCounter™ resolves each tail number to its real aircraft type from a curated registry before anything loads. If even one tail can't be matched, the file is held rather than letting an "Unknown" bucket quietly poison every aircraft report downstream.

Asks: is every aircraft identified?

Shape check

This is a real Logicraft export

Before a single row is read, the columns are verified against the expected schema — date, origin, destination, flight, tail, ticket number, gross, net, airline, supplier and more. A missing column usually means the wrong file entirely, so the upload halts up front with a clear message and zero data touched — no panicked rollback after parsing tens of thousands of rows.

Asks: does this file even look right?

Identity check

Every row is uniquely yours, forever

Each ticket gets a permanent identity built from its originating airport, date and ticket number — ANC_2026-01-15_944193. Two rows that would collide get a suffix instead of being silently merged. That stable ID is what makes duplicate detection, dashboards, deletes and rollback possible across every later step.

Asks: can we tell each row apart from every other, ever?

Conflict check · human in the loop

Volume, invoice & schedule reconciled — duplicates surfaced

FuelCounter™ asks which incoming IDs already exist and shows a field-by-field diff for every match. It cross-checks ticket gallons against the supplier invoice, validates the flight against the actual flown schedule from FlightStats, and flags volume mismatches, price variances and ghost flights. The operator sees a full preview — rows, dates, airports, duplicate count — then chooses to skip or overwrite for the whole file. The system can detect a duplicate; only a human decides which version is correct.

Asks: does this already exist, and does it match reality?

Commit & broadcast

Written, totaled, and live for everyone

On execute, the rows are committed in batches with a timestamp, the per-airport / per-airline / per-month totals are adjusted so dashboard counts always match the underlying tickets, and a version stamp is bumped. Every open browser notices the change and refetches automatically — nobody hits refresh. A separate audit record logs who uploaded what, when, and over which dates.

Asks: is it written, and does everyone know it changed?

Who we serve

One ledger, three vantage points

Validated fuel data answers a different question for everyone who touches it — but it's the same audited record underneath.

Airlines

Stop paying for fuel you never burned

Match every uplift to the flight that actually flew. Ghost flights, double-billed tickets and volume overstatements surface before they hit the ledger — so what you reconcile is what left the truck.

Fuel suppliers

Invoices that survive the audit

Reconcile delivery tickets against your own invoices line by line. Price variances and quantity disputes are caught early with the source document attached — fewer chargebacks, faster settlement.

Into-plane & M&O

Clean data from the ramp up

Handwritten ramp tickets are resolved, identified and matched against the schedule automatically — so the operations team feeds trustworthy numbers into billing, drawback and tax without re-keying.

Two ways to run it

Web app for ad-hoc, server for high volume

The same five gates run in both modes. Reconcile a single batch by hand in the browser, or wire FuelCounter™ into an automated pipeline for continuous, hands-off validation at scale.

	Web validation	Server validation
Throughput	One batch at a time, interactive	Continuous, tens of thousands of rows per run
Scheduling	Operator-triggered upload	Automated on file arrival or fixed cadence
Conflict review	Side-by-side diff, human decides skip / overwrite	Rule-driven; exceptions queued for review
Integration	Drag-and-drop admin upload page	FlightStats, supplier EDI, FMS feeds via API
Recovery	Re-upload last backup snapshot to roll back	Rebuild aggregates & replay from raw rows
Best for	Ad-hoc reconciliation, spot checks, smaller stations	High-volume hubs & always-on reconciliation

FAQ

FuelCounter™, answered

What exactly is a "validation gate"?

A gate is one question the data must answer before it can advance — is every aircraft identified, does the file have the right shape, is each row uniquely identifiable, does it conflict with what's stored and match the schedule, and is it committed and broadcast. A "no" at any gate stops the file, and everything upstream rolls back cleanly so you never end up with half-loaded data.

How does FuelCounter™ know the actual flight schedule?

It validates each ticket against the airline's actual flown schedule sourced from FlightStats. If a ticket references a flight that never operated, it's flagged as a ghost flight rather than being added to your totals — so you don't reconcile fuel for aircraft that weren't there.

What about false positives — won't legitimate tickets get flagged?

Flags don't delete or alter anything; they queue an exception for human review. Gate 4 keeps a person in the loop for exactly this reason: the system can detect a duplicate or a variance, but only an operator decides whether the new version is more correct than the old one. Nothing is overwritten without being seen and acknowledged.

How does this connect to FuelScanner™ and DutyCounter™?

FuelScanner™ captures the ticket into 32+ structured fields; FuelCounter™ validates it against invoices and schedules; the audited result then flows into DutyCounter™ for duty drawback and FuelTaxPro™ for filing. It's one continuous ledger inside FuelDeck™ — data is entered once and trusted everywhere.

If an upload was a mistake, can we undo it?

Yes. Each commit is timestamped and audit-logged, and totals are adjusted so dashboard counts always match the underlying tickets. If a batch was wrong, re-upload the most recent backup snapshot to roll back to the previous state, or rebuild the aggregates directly from the raw rows.

Reconcile every uplift against reality