03 / Confidential System
Fuel Custody &
Reconciliation
Platform
A full-stack fuel governance platform for tracking, authorizing, reconciling, and auditing fuel movement across stations, tanks, pumps, vehicles, tanker deliveries, and field devices.
Django · PostgreSQL · Redis · React · Next.js · TypeScript · Docker
Figure 01 — Representative operating map showing field devices, edge control, fuel events, reconciliation, alerts, reports, and audit evidence.
01 / Product Context
What the product is
A multi-tenant operational platform that governs fuel movement across the supply chain — from depot loading and tanker transport to station delivery, dispensing, authorization, and reconciliation.
02 / Operational Problem
Why it matters
Fuel losses, unauthorized dispensing, weak traceability, and manual reconciliation create financial leakage and compliance risk. The system brings every liter into a traceable, reviewable, and auditable workflow.
03 / Contribution Scope
My role
Contributed as a software engineer across backend and frontend modules within a larger product team, supporting API-connected workflows, event visibility, reconciliation/reporting flows, authentication, and operational dashboard behavior.
02 / Domain Flow
Fuel movement lifecycle
Fuel custody starts before the station transaction. The system models the lifecycle from loading and transport through delivery, tank movement, pump dispensing, vehicle authorization, and final reconciliation. This makes fuel movement itself traceable, not only the location of a truck or a manual station report.
Figure 02 — Fuel movement lifecycle from loading to final audit record.
03 / Rules Engine
Reconciliation logic
Reconciliation compares independent signals instead of trusting a single source. Delivery volume is compared against actual tank increase, pump dispensing is compared against tank decrease, and fleet transactions are checked against vehicle authorization and policy limits.
Reconciliation model
The platform does not trust one source of truth. It compares independent records from field devices, tanks, pumps, vehicles, and delivery events. When those records do not match, the system produces an operational output for review, reporting, or audit.
01 / Rule model
Delivery reconciliation
Tanker delivery vs station tank receiving
Compares the delivery volume reported by the tanker against the actual increase recorded by the station tank system. If the difference is outside the allowed tolerance, the system surfaces it as an investigation item.
Evidence compared
Evidence source
Reported tanker delivery
Delivery volume from tanker record
Evidence source
Actual tank increase
Tank-level change from ATG reading
Output
Variance alert / investigation record
Used by operators to review delivery mismatch
02 / Rule model
Station reconciliation
Pump dispensing vs tank movement
Compares the volume dispensed by pumps against the expected decrease in tank level. This helps detect shrinkage, meter mismatch, leakage, manual reporting gaps, or suspicious station activity.
Evidence compared
Evidence source
Pump dispensed volume
Pump transaction / totalizer reading
Evidence source
Tank level decrease
Expected tank movement from ATG
Output
Daily reconciliation report
Used for station review and operational reporting
03 / Rule model
Fleet authorization
Vehicle identity vs fueling policy
Checks whether the vehicle identity and fueling transaction match the allowed fleet policy. This helps prevent unauthorized fueling, card misuse, and uncontrolled fleet consumption.
Evidence compared
Evidence source
Vehicle identity
RFID tag / license-plate recognition
Evidence source
Fueling transaction
Pump event linked to vehicle
Output
Fleet fuel record / policy exception
Used for fleet consumption and audit history
Figure 03 — Independent signals are compared instead of trusting a single source.
04 / Reliability Model
Offline-first authorization
Fuel operations cannot depend on perfect connectivity. The edge layer supports local policy checks, queues events during interruptions, and synchronizes them back into the central audit trail when connectivity returns.
Figure 04 — Local authorization and queueing preserve operational continuity and audit evidence.
Technical Contribution Evidence
System contribution areas
01
Backend workflows
API-connected flows for fuel authorization, OTP authentication, RFID/license-plate integration, loyalty/wallet behavior, and reconciliation-related workflows.
02
Authorization and identity
Vehicle and user identity flows support controlled fueling, policy checks, and traceable transaction records across field operations.
03
Reconciliation and reporting
Rules-driven comparison of delivery, tank, pump, and fleet signals helps surface mismatches, exceptions, and operational reports.
04
Event visibility
Fuel events are treated as auditable records with device source, station context, vehicle identity, timestamps, and reconciliation status.
05
Offline-first reliability
Edge-side buffering and local authorization thinking supports continued station operations during connectivity interruptions.
06
Operational dashboards
Dashboard and reporting views translate raw field activity into exceptions, compliance records, KPIs, and management visibility.
Technical Environment
Stack used across the product environment.
What this project demonstrates
This project demonstrates operational software engineering: systems where reliability, traceability, authorization, and domain rules matter as much as the interface. The value is not the screen alone; it is the system’s ability to turn field activity into trusted operational evidence.