Skip to content
Uzair Saleem · software engineer

Case study

Sat-Raj, Inc.: a fuel distributor's office, automated

How a family-run gasoline and diesel distributor in New Jersey went from spreadsheets and retyping to same-day automated invoicing, without leaving QuickBooks Desktop.

Role
Software engineer, sole developer, ongoing
Stack
Next.js, TypeScript, PostgreSQL, Prisma, AWS
Integrations
Samsara telematics, DTN terminal feeds, QuickBooks Desktop
Live
satraj.inc

Watch it run

The situation

Sat-Raj delivers gasoline and diesel to gas stations across New Jersey and Pennsylvania. Before this project the office ran the whole business by hand. Every morning someone computed prices in a spreadsheet from terminal rack costs and emailed them customer by customer. Drivers photographed their delivery tickets, and the office retyped each one into QuickBooks Desktop. Every per-gallon fuel tax was added as a separate invoice line, from memory. Invoices went out days after the fuel did, and one mistyped number meant a wrong bill.

I designed and built the platform that replaced this, and I run it today. Here is what was actually wrong, and what I did about each piece.

The problems and what I built

01

Daily pricing took an hour and lived in one person's head

The morning routine: pull rack costs, add margin, freight, and the right state's fuel taxes for each customer, then write the price emails one by one. An hour on a good day, and nobody else in the office could do it.

What I built: the operator types the day's rack costs once. The system computes every customer location's price, margin and freight per station, NJ or PA taxes by rule, and sends each customer their price email automatically. Customers with several stations can share a price group: one location defines the group's fuel menu and each station keeps its own freight. The morning run is now about 90 seconds.

02

Delivery tickets were retyped into QuickBooks by hand

Drivers already submitted tickets through Samsara, a photo plus typed fields, but from there everything was manual. And hand-typed location names are unreliable, so even knowing which customer received the fuel was guesswork.

What I built: a scheduled sync pulls every ticket from Samsara's API. A GPS matcher reads where the truck actually stopped during the delivery, matches the position against geofences, and resolves the exact customer location. The driver's typing never decides anything, the truck's position does. Tickets the matcher cannot resolve, no GPS, unknown site, two possible geofences, queue on a dashboard with one-click assignment.

03

Matching a delivery to the right price was error-prone

Prices change daily and differ per customer, per station, and per fuel. Billing a delivery meant finding the right price in old emails and spreadsheets.

What I built: every delivery automatically matches the price sent to that customer that morning, and gallons reconcile against the ticket. Their real business rules are encoded: a clear diesel load of 6,500 gallons or more bills at the full-load price; split loads, one truck serving two customers, get divided into portions that invoice separately; a delivery that arrives before its price was sent re-prices itself when the price arrives. Hand-priced deliveries still get their taxes derived correctly by state.

04

QuickBooks Desktop has no modern API

The bookkeeper runs QuickBooks Desktop on a PC. The vendors who "solve" this problem want distributors to abandon QuickBooks for a five-figure ERP. That was never going to happen here.

What I built: a Web Connector service, the SOAP protocol QuickBooks Desktop actually supports, which the bookkeeper's PC polls every 15 minutes. One click turns a checked delivery into a fully itemized invoice: fuel at its net rate, then every per-gallon tax as its own named line, federal excise, state fuel taxes, spill fees, 16 tax rules across NJ, PA, and federal, each mapped to the exact QuickBooks items the bookkeeper already uses. The customer list syncs back from QuickBooks live. Batch draining, retries, and duplicate guards mean a dropped connection never double-bills anyone.

05

Automation nobody trusts is automation nobody uses

An office that has been burned by software checks everything twice, which erases the time the software saved.

What I built: 169 automated tests run on every change. Syncs are idempotent, so running one twice changes nothing. Every price and invoice carries an audit trail. And the dashboard never hides a problem: when something needs a human it says exactly what is wrong, a missing price, an unmatched location, gallons that do not reconcile, and offers the fix right there.

Where it stands

Hundreds of invoices

Pushed into QuickBooks Desktop through the pipeline, in production daily.

Same day

Ticket to invoice. It used to take days.

90 seconds

The morning pricing run, down from about an hour.

Nothing ripped out

The office kept QuickBooks Desktop, their item list, and their process.

If your office looks like the before picture

Email me one line about your operation and I will walk you through the system on your own numbers.

Email meSee the walkthrough