Fuel retail software for every station, sale, invoice, and exception.

It can connect station sales, tenders, wet-stock and convenience inventory, vendor invoices, items, prices, deliveries, adjustments, reporting, user roles, alerts, and head-office workflows. The exact boundary depends on the existing POS, forecourt controller, back-office, accounting, payment, and supplier products.

Keep a supported POS when it records station transactions reliably and exposes an approved way to read or exchange the required data. Build an integration and operating layer when the real gap is cross-location visibility, invoice work, inventory, vendor control, or reporting. Replace only when the POS itself blocks essential operations and a supported migration path exists.

No. Generic POS produces pump authorization delays, incomplete fuel reports, and shift-end reconciliation gaps requiring manual correction. Pump controller communication is the core differentiator of purpose-built systems. The measurement-versus-records frame: the forecourt is a measurement problem. Hardware determines what is possible. The counter is a records problem: procedural failures like no counts, shared logins, payments from memory. Wet-stock reconciliation needs tank-gauge integration: deliveries in versus litres out versus tank remainder, flagging shrinkage from meter drift, evaporation, or theft. If shop stock is a list of item names with no quantities, the shop is still run on eyesight.

The price-propagation test is the non-technical buyer's single best demo question. Prices must flow back-office to pump display to receipt to forecourt signage fast. A delay risks selling fuel at the wrong price: a customer issue plus a reconciliation problem. Multi-site operators need simultaneous price-push and confirmation it propagated. Vendor screening questions before the meeting: do you read or control my dispensers? Do you gauge tanks or reconcile wet stock? Can I count the minimart and lubricants? Show me a compliant fleet invoice printed at the counter. A vague answer on pump brands means partial integration discovered at installation.

Offline transaction processing is a baseline expectation, not a premium feature. A live-connection dependency is a hard stop at peak hours, with lost sales plus reconciliation cleanup afterward. The three-number framework for reconciliation: physical means dispenser litres versus tank dips; record means what was sold, per attendant and shift; money means cash, mobile money, card, credit. Gaps between them split recording problems from money problems. Daily and shift variance flags where to look. Can the station keep operating when the internet drops? Queue records locally, retry without duplication, expose delay and failure. That is the requirement.

Four rituals. One: the generic-POS test. Adapted POS equals pump authorization delays plus shift-end manual reconciliation. Two: the price test. Change one grade and watch it reach every pump, receipt, and sign. Three: the offline test. Kill the network; the station keeps selling. Four: the invoice test. Store the source invoice, extract suggested fields, let staff confirm or correct, and retain the link between document and accepted record. Integration without replacement: confirm the exact POS system and version, approved access, sample records, then connect, not replace.

A paid phase can cover a station-system audit, representative data mapping, a connector proof, or an invoice OCR proof. A focused production v1 grows with POS vendors, station count, wet-stock depth, pricing, payments, accounting, hardware, OCR variation, migration, and rollout support. The price is fixed and agreed in writing before the phase begins.

Timing depends on vendor access, hardware variation, source data quality, the number of integrations, and rollout size. The scope names the station cohort, system access, evidence, exclusions, and timing before a paid phase begins.

The existing POS and forecourt products retain their approved local operation. A custom connector can store agreed data locally and sync later, but the exact behaviour depends on the station system, hardware, data access, security, storage, and vendor terms. The scope defines queue limits, retries, duplicate prevention, alerts, and reconciliation.

OCR can extract suggested vendor, product, quantity, and price fields for staff review. Accuracy depends on document quality, formats, handwriting, product vocabulary, and validation rules. The workflow should preserve the source image, confidence or exception state, human confirmation, and the final authoritative record.

The direct RaftLabs case integrated Gilbarco Passport. That does not guarantee access or compatibility with another version, region, hardware estate, contract, or vendor. We confirm the exact environment, supported access, sample data, security, licensing, and vendor cooperation before production scope is locked.

Use stable source identifiers, timestamps, location and device context, explicit mappings, idempotent processing, retry queues, sync health, exception review, and reconciliation reports. The system should show delayed or incomplete records rather than silently blending them into a total.

The fuel retailer, POS and forecourt vendors, payment providers, equipment providers, accountants, and qualified advisers retain those responsibilities. RaftLabs builds the agreed software and integration scope. Software delivery alone does not certify a station, guarantee compliance, or make inventory and financial records correct.