Fuel retail is a wet-stock business, not a boxed-goods business. Every litre pumped has to reconcile back to a nozzle meter reading, a tank dip, and cash or fuel-card settlement at shift close — and a variance of even a fraction of a percent across a busy forecourt is real money leaking or being over-charged. ERPNext gives you a solid Sales Invoice, Stock Ledger, and Payment Entry backbone, but out of the box it has no concept of an opening/closing nozzle reading, a calibrated tank dip converted to litres, a pump-to-tank mapping, or a shift cash handover. Operators end up reconciling all of this in spreadsheets that never tie back to the accounting ledger.

ECOSIRE builds a proper Frappe app that adds the forecourt domain on top of ERPNext rather than bolting it on. We model the physical site as DocTypes — Fuel Tank, Pump, Nozzle (with its bound tank and product), Shift, Shift Reading, Tank Dip, and Fuel Card Account — and post the resulting movements through native ERPNext Stock Entries, Sales Invoices, and Journal/Payment Entries so your GL and stock valuation stay canonical. Nozzle throughput (closing meter minus opening meter, adjusted for test/calibration pours) is computed and reconciled against dispensed sales; tank dips are converted through per-tank calibration charts into volume and compared to book stock to surface shrinkage, evaporation, or delivery discrepancies as a variance report.

The logic lives where it belongs in Frappe. hooks.py doc events (validate, on_submit) enforce that a shift cannot close with an unbalanced meter-vs-sales or cash-vs-collection delta beyond your tolerance; whitelisted server methods expose reconciliation and dip-entry endpoints for the forecourt POS and any handheld dip app over the Frappe REST API; scheduler events roll up daily wet-stock variance and can flag tanks trending toward reorder. Client Scripts drive the attendant-facing POS — nozzle selection, litres/amount entry, fuel-card lookup against the customer's fleet account and credit limit — and combine dispensed-fuel and convenience-store (shop) lines on a single ticket. Role Profiles and permission rules separate the attendant, the shift supervisor who authorises handovers, and the accountant who reviews variance, with the full audit trail ERPNext already provides.

Because this is build-to-order, you receive an app scoped to your actual site layout, product slate, fuel-card partners and reporting needs — not a generic template you have to bend. After a short scoping call we confirm the DocType model and reconciliation rules, build against ERPNext v15/v16, and run UAT on a staging bench with your data before go-live. Typical delivery is 2–4 weeks from confirmed scope, and you get the full git repository, installable source for your version, and a post-go-live support window so real forecourt edge cases get handled, not left to spreadsheets.