Gas station software that reads the Gilbarco POS instead of replacing it

The situation

The operator ran more than 40 gas stations in the US, every one on a Gilbarco Passport POS. Each POS knew its own sales. None of them shared stock, invoice, or price data with the others. Inventory lived in spreadsheets, staff typed vendor invoices in line by line, and a price change meant updating every station.

Replacing 40+ POS terminals wasn't on the table. So the job was to work with the Passport systems already in place: read their sales, write price and product changes back, and turn vendor paperwork into stock records without retyping.

RaftLabs built three connected pieces: web apps for owners and station admins, a desktop app that syncs each POS with the cloud, and an AI pipeline that reads vendor invoices. Reading the characters is only the first half of that job. The platform also has to answer which number is the total, which line is which product, and how certain the read was, because a wrong total that reaches the stock record unreviewed costs far more than one that gets flagged. The AI turned out to be the easier part. The POS integration carried most of the risk: Gilbarco's integration documentation was thin, and vendor support was slow.

The decisions that shaped V1

• The Gilbarco integration had to be worked out by trial and error

  Passport's integration documentation was thin. Gilbarco support answered slowly, and the time-zone gap made each question cost days. Waiting on the vendor would have stalled the whole project.

  So we worked with the files the POS already exchanges with its back office. Passport writes sales to a BOOutBox folder and imports changes from a BOInBox folder. A desktop app on the station's back-office PC reads the outbox and writes to the inbox over the local network share. Getting the formats and timing right took many rounds of trial and error.

  The result: no new hardware at the station, and no change to how cashiers use the POS.

• Real-time sync gave way to a 10-minute batch

  The original plan said real-time sync. Discovery showed a problem with that. The sync compares files before upload so the same sales file never gets counted twice, and that check made short intervals unsafe.

  V1 syncs in batches about every 10 minutes. Real-time sync moved to a later version.

  The trade is a few minutes of freshness for stock counts owners can trust. A duplicate upload would double-count sales and corrupt every figure downstream of it.

• Stock math had to follow the coffee cup, not just the barcode

  A POS line item isn't the same as a stock movement. Selling a coffee also uses a cup and a lid. A refill uses supplies but isn't a sale. The same product can sit on the shelf as single units and in unopened boxes.

  The platform converts each XML sales file to JSON and turns every line into stock movements. Supply items link to the products that consume them. Refill items deduct supplies without counting a sale. When single units run out, the system draws from box stock and tracks how many boxes remain across boxed and loose items. A database trigger flags low stock, and a scheduled job keeps statuses current.

  Mixed unit and boxed stock was the case that caught us off guard. It now sits inside the deduction logic instead of in a manual count. For comparable inventory management software, put unit-and-box rules in the first data model.

• Invoice scanning went through three model plans

  Discovery tested six OCR tools and three LLMs, then recommended AWS Textract with Claude 3.5 Sonnet through Zerox. The first build, in April 2025, sent each PDF page to Claude 3.7 Sonnet and parsed the text it returned. In May 2025 the pipeline moved to Gemini 2.5 Flash through the Vercel AI SDK, which returns the whole invoice as one schema-checked object. It started on a preview build and moved to the general release in June.

  Fuel invoices and product invoices follow separate extraction paths. Each product line is checked against UPC barcode data from UPCitemdb, one of five UPC APIs compared in discovery. The AI then maps each line to the store's categories. Staff see the result as suggestions and confirm before anything touches stock. Most invoice processing automation works best in this order: the model extracts, a reference database checks, and a person confirms.

  The UPC lookup and AI categorization slowed every scan. The fix was a Redis cache in front of both: products the lookup finds stay cached, and empty results expire after five minutes so a newly listed UPC gets another try. It's the technical decision we're proudest of on this project. No extraction accuracy or speed benchmark has been verified for publication.

• Refills were quietly inflating the sales numbers

  The raw transaction data couldn't be taken at face value. Coffee and fountain drink refills showed up as units sold, which inflated quantity and revenue on every report. The numbers looked fine until someone reconciled them.

  Sales counts now exclude refills. Refunds, discounts, and net sales sit apart from gross. Every card, chart, and table reads from one set of numbers, so an owner never sees one total on the dashboard and another in the table. Charts show the top sellers plus a grouped "Others" total, so a category with dozens of products stays readable and the total stays correct.

1. Station

   Gilbarco Passport back office

   The POS writes sales files to its outbox folder and reads price and product changes from its inbox. The cashier's workflow doesn't change.

3. Sync

   Tauri desktop app

   Signs in through AWS Cognito, moves new outbox files to S3, and writes pending change files into the inbox. It retries every five minutes when a connection fails.

5. Processing

   AWS Lambda

   Parses XML into JSON, applies stock movements, writes Passport files for price and product changes, and runs invoice extraction with Gemini, UPCitemdb, and a Redis cache.

7. Data and apps

   PostgreSQL, Hasura, and three web apps

   Stores stations, products, supplies, invoices, and stock. Triggers and scheduled jobs keep stock and expiry status current for the owner, station admin, and super admin apps.

1. Staff check AI-read invoice lines instead of typing them

   Staff scan or upload a vendor invoice. The AI returns the vendor, invoice number, date, total, and line items. Each line is checked against UPC data and mapped to a category. Staff fix anything that's wrong and save. Fuel delivery invoices and product invoices each have their own extraction path.

   

2. Each POS syncs through a desktop app that runs in the background

   A Tauri app sits in the system tray of the station's back-office PC and can launch at startup. It watches the POS outbox, uploads new files, and delivers pending price and product files to the POS inbox. Owners see each station's last connection and sync time in the web app, so a station that stops syncing is easy to spot.

   

3. Price changes queue for the next sync, with status tracked

   Owners change a product or fuel price once. The platform writes a Passport file, stores it, and marks it pending. The sync app delivers it to the station's POS on its next cycle. Price history stays on record, so owners can see what changed and when.

   

4. Reports that reconcile, including a printable store close

   Owners see supplies and c-store sales by station, category, and period, each with a trend against the previous period. Barcodes carry no expiry date, so staff type it on the first add and the platform fills it in after that. A database procedure moves stock from fresh to expiring soon to expired. The end-of-day store close report downloads as a print-ready PDF.

   

How it runs

React

Three role-based web apps (owner, station admin, and super admin) share components and data hooks in one Nx monorepo, so a reporting fix reaches every app at once.

Tauri and Rust

The sync app runs on the back-office PCs stations already own. Tauri with a Rust core gave a small system-tray app with native network-share access, auto-start, and auto-update, without bundling a full browser runtime.

Hasura and PostgreSQL

Stock rules live next to the data. A trigger sets low-stock status, a stored procedure moves shelf-life status, and Hasura exposes the model to all three apps through GraphQL.

AWS Lambda

XML parsing, stock deduction, invoice extraction, and scheduled jobs for daily sales, stock snapshots, and inventory status run as functions, so 40+ stations syncing on the same cycle don't need servers sized in advance.

Gemini 2.5 Flash via the Vercel AI SDK

Structured output returns each invoice as a schema-checked object. That replaced page-by-page prompts and free-text parsing in the first version of the pipeline.