Home · Solutions · Operations & production · Tanks reconciled nightly, losses visible by morning
Solution · Operations & productionThe gauge says one thing, the tills another: by morning you know why, station by station
Tanks reconciled nightly, losses visible by morning
Every night a robot lines up gauge readings, dispenser sales and received deliveries, closes balances within tolerance and raises above-threshold differences as cases with the tank’s history and a suspected cause.
Executive summary
Three sources describe the same fuel differently: tank gauges, dispenser meters and delivery documents. A person reconciles them occasionally, in a spreadsheet.
Every tank’s balance computes itself, nightly, by one rule. In-tolerance differences close themselves; above the threshold they become a case with history and a hypothesis.
A leak, a calibration drift and theft stop having weeks to dissolve into statistics. The morning after, they are a list item with an owner’s name.
tank gauge readings; sales from BOS/POS; deliveries from the ERP; cases and a loss dashboard in Microsoft Teams and Power BI
Business problem
Fuel in three versions
Every station knows its fuel from three places at once. The tank gauges measure what is physically there. The dispenser meters, dumped into the till system, say what was sold. Delivery documents say what came in. These three numbers never agree to the litre and they do not have to: fuel moves with temperature, gauges have tolerances, and evaporation is physics, not accounting.
The problem starts where nobody knows how much difference is normal. Reconciliation is manual, on selected stations, typically weekly or monthly. The spreadsheet has as many versions as there are regional managers, and the alarm threshold is the intuition of whoever happens to be looking.
At that rhythm, events lose their shape. A one-night step loss, a slow drift after a gauge replacement and a delivery booked to the wrong tank all look identical a month later: one negative number. Finding the cause means walking back to days nobody remembers, through data nobody archived in one place.
The network pays twice. Once in litres that disappear unexplained. Again in the time of people who re-type readings into a spreadsheet every month only to end with a number that cannot answer where it came from.
How it works today
Below is what the work looks like before anything is automated.
- PersonThe station manager writes down or exports gauge readings and sales reports, each in its own format
- PersonSomeone at head office pastes the data into a reconciliation spreadsheet, station by station, tank by tank
- Risk of errorDeliveries received across midnight and tank-to-tank transfers enter the balance by hand, or not at all
- WaitingThe balance is built weekly or monthly, so an event waits in the data until someone computes it
- Risk of errorThe alarm threshold is intuition: the same difference triggers a phone call at one station and passes unnoticed at another
- Risk of errorOnce a loss is found there is no daily history, so the cause stays a guess and the case ends as a write-off
Why the current process costs more than it appears
The bill that never shows up in a budget.
- Unexplained litres get booked as natural loss because that is the fastest path. The norm is made up, and it grows year after year.
- A leak found after weeks is no longer a service call but an environmental case: soil, neighbours, paperwork. The cost gap between those two scenarios exceeds the entire reconciliation budget.
- Manual reconciliation covers as many stations as there are people. The rest of the network is out of control precisely in the months when nobody has time.
- Calibration drift under- or over-states sales for months. Nobody sees it, because a single day fits within tolerance and the trend only shows on a chart nobody draws.
Cost of inaction
The rows above price the two things that are easy to count: people’s time and unexplained litres at a typical proportion. The third row cannot honestly be priced on a page, because the cost of environmental damage depends on ground, neighbours and reaction time; what is known is that every day of delay raises it.
The biggest item is often the one missing from the table: a loss norm set “historically”. If for three years it has absorbed everything nobody explained, it is not a norm, it is consent to a fixed percentage of loss.
A model organisation with realistic proportions – the numbers exist so you can run the same maths on your own data; they are not a client result.
A Polish network of forty owned and franchised stations: three to five tanks per station, remote-read gauges on most sites, a BOS dumping sales nightly, an ERP holding delivery documents, Microsoft 365 across the company.
1.2m litres of monthly sales, around 260 tanker deliveries, 160 tanks to balance every day.
Head office reconciles tanks once a month in a spreadsheet, from exports sent in by managers. Alarms announce themselves: by phone, when the difference is already large.
Two people lose several days a month gluing exports together, and still no daily balance exists: an event from the 3rd is visible on the 5th of the following month at the earliest.
A robot pulls gauge readings, sales and deliveries nightly, computes each tank’s balance by one versioned rule with per-tank thresholds, closes what is in tolerance and raises differences as Teams cases with a trend chart and a first classification: step, drift or delivery mismatch.
In the modelled case a daily balance exists for the whole network from night one, and the loss conversation changes subject: from “how much are we missing” to “which three tanks need a decision”. Model numbers, not anyone’s ledgers.
Proposed solution
We start not with a robot but with the balance rule: what enters the reconciliation (gauge readings, meter sales, deliveries, tank-to-tank transfers), at which cut-off hours and with what per-tank tolerance. The rule is written down with your operations owner and versioned from day one.
Each night the robot collects data from every station, computes the balance tank by tank and stores the result with its full component history. In-tolerance differences close themselves and feed the tank’s statistics. An above-threshold difference becomes a Microsoft Teams case with a chart of recent weeks, the balance components and a first classification, because a step loss at night looks different in data from a slow calibration drift, and both look different from a delivery booked to the neighbouring tank.
Decisions stay with people: send the service crew, order a control measurement, file a claim, or correct the delivery booking. The robot makes sure every case has an owner and a closure, and a Power BI board shows the network in one view: tanks in tolerance, open cases, loss trends per station and per supplier.
UiPath Orchestrator: scheduled nightly runs, queues per station, retries and a full audit trail; UiPath Integration Service connector for Microsoft Teams; UiPath Action Center task notifications; a Microsoft Power BI board published to a Teams channel
The balance rule with per-tank thresholds and its versioning, collection and normalisation of station data, the reconciliation engine with first-pass classification, cases with closure, and the network loss board
Gauge readings via the tank monitoring system or per-station exports; sales from BOS/POS via file interface or API; delivery documents from the ERP; optionally temperature data for volume correction
How the automated process works
- AutomationAt night the robot collects gauge readings, meter sales and deliveries for every tank in the network
- AutomationThe balance is computed by a versioned rule with per-tank thresholds; the full set of components is stored
- SystemIn-tolerance differences close themselves and feed the tank statistics and the loss norm
- AutomationAn above-threshold difference receives a first classification: step, drift or delivery mismatch
- PersonThe case reaches its owner in Microsoft Teams with chart and components; a person decides on service, measurement or correction
- PersonThe loss board shows the network in one view, and cases without closure return to the list with a name
Human-in-the-loop model
Automation handles
- Nightly collection and normalisation of data from all stations, the same way every time, with the rule version recorded
- Every tank’s balance, self-closing of in-tolerance differences and first-pass classification above the threshold
- Making sure every case has an owner, a deadline and a closure, and keeping the loss board current
People decide
- Per-tank tolerance thresholds and every change to the balance rule
- The decision in every case: service, control measurement, claim, or booking correction
- The loss norm accepted for accounting and conclusions towards suppliers or stations
Before and after
Systems and integrations
The stack is short on purpose: one engine, one execution layer, one place where a person decides.
Inputs
- tank gauge readings
- dispenser meter sales in BOS/POS
- delivery and transfer documents in the ERP
- per-tank thresholds and the balance rule
Automation layer
- UiPath Orchestrator
- UiPath Robots
- UiPath Integration Service
- UiPath Action Center
Target systems
- a daily balance register with component history
- loss cases in Microsoft Teams
- the network loss board in Power BI
Human touchpoints: UiPath Action Center cases in Microsoft Teams; the loss board in a Teams tab; a weekly norm review with operations
Technologies used
nightly runs per station, queues, retries, credential store and a full audit trail
Apublishing cases and summaries to operations channels
Aloss cases decided by people where operations already work
Athe loss board: balances, cases, trends per station, tank and supplier
Alevel and temperature readings via the monitoring system’s interface or exports; accuracy and tolerances per the gauge vendor’s documentation
BHow we deliver this
From this description to a running process
We deliver this solution through our process automation service: first we measure the process on company data, then we build, test and maintain the robots. SAP integration is handled by our SAP team.
Industries
Case studies
Delivered client work is described under Case studies.
Illustrative economic model
Numbers you can check against your own data.
“Unexplained” does not mean “stolen”: it is the sum of events that a monthly rhythm could not separate into calibration, temperature, deliveries and real loss. The model prices the ignorance itself. €24 an hour is an example full cost of a seat; the volume and the percentage belong to this scenario, not to a client’s ledgers.
Run the numbers on your data
An illustrative estimate based on your inputs. It models freed capacity, not promised savings.
Business benefits
- A daily balance exists for the whole network, not only for the stations people had time for
- A leak, a calibration drift and a wrong delivery stop looking alike: the first classification routes the case to the right person at once
- The loss norm stops growing by neglect, because it is computed from in-tolerance tanks rather than from whatever nobody explained
- Conversations with suppliers and stations rest on balance history, not on impressions
- Head office gets days back every month, and station managers stop being couriers of exports
The management view
- Control over fuel stops depending on who had time to open the spreadsheet, and when
- Every difference has a record: balance components, rule version, the decision and a closure with a name
- Environmental exposure shrinks in the only measurable way: by cutting the time from event to reaction
Board-level KPIs
above-threshold differences per 100 tank-days · time from event to decision · share of differences with an established cause · loss norm accepted for accounting · cases without closure at week’s end
Security and governance
The automation has exactly the permissions it needs. Not one more.
- The robot reads station systems with a technical account of minimal rights; it changes nothing in the BOS or the ERP beyond its own balance register
- Every balance keeps its full components and rule version, so a March decision can be reproduced in November to the litre
- Thresholds and the balance rule are versioned and changed only by the designated operations owner
- No personal data is involved: the balance deals in tanks and documents, not people; cases point at roles, not culprits
- Cases, boards and registers stay in your Microsoft 365 tenant, and the robots run in the EU region of UiPath Automation Cloud
Why now
Retail fuel margin is too thin to fund a standing, unexplained percentage of loss. At today’s volumes the gap between a “historical” norm and one computed from statistics is real money every month.
Remote-read gauges are already on the stations: the data exists and flows nightly, nobody just assembles it into a balance. It is the rare automation whose most expensive piece of infrastructure is already paid for.
Environmental requirements are not getting softer, and the only variable a network controls on the day of an event is detection time. A daily balance cuts it from weeks to hours.
Relevant executive roles
The network stops being forty separate spreadsheets; losses become one case list with owners and a trend
For the first time the loss norm used in the accounts has a basis in data rather than in a history of neglect
Time from event to reaction, the one variable every environmental case turns on, is measured and reported
Common questions and objections
It alarms on levels and gauge faults, and rightly so. It does not, however, line the gauge up against till sales and ERP deliveries, and only that trio says whether fuel is really gone or only on paper. The automation does not replace monitoring; it closes the balance monitoring cannot see.
There will, and the model assumes it: in-tolerance differences close themselves and build the norm. What changes is the fate of differences above the threshold: instead of dissolving into a month, they are a case with a chart and an owner the next morning.
Scopes differ and contracts differ. The balance also works in a reduced variant: gauges plus deliveries give physical control of the tank, and the sales leg is added where the data exists. It is worth re-reading the franchise agreements though: the right to sales data exists more often than it is used.
When this is not the right solution
- A single station without remote-read gauges: the first investment is telemetry, not balance automation
- A network where sales never leave the dispenser meters into any system; without its second leg the balance remains a measurement, not a reconciliation
- The expectation that the system will name a culprit: classification says what a difference looks like, not who caused it; the investigation stays with people
A question for the next management meeting
How many litres did we book as natural loss last year, and what part of that number has any explanation beyond nobody having had the time to count it?
Implementation approach
Scope without ambiguity, before anything is signed.
We deliver
- The balance rule with per-tank thresholds, written down with operations from your historical data and versioned from day one
- A nightly reconciliation of all tanks with a full component record and first-pass classification of differences
- Loss cases in Microsoft Teams with an owner, a deadline and a closure
- The network loss board in Power BI: balances, cases, trends per station, tank and supplier
- A parallel run against the current spreadsheet through the first full month, and post-go-live care
We need from you
- Three months of history: gauge readings, daily sales, deliveries, current reconciliations
- A designated operations owner to approve thresholds and own the balance rule
- Technical access to the tank monitoring system, BOS/POS exports and ERP delivery documents
Stages
Discovery
A month of data from all three sources read end to end: where the gaps are, which tanks are noisy, what currently passes for a norm
Rules
The balance rule, cut-off hours and per-tank thresholds approved by operations
Build
Collectors, the reconciliation engine, difference classification, Teams cases and the Power BI board
Parallel run
The robot computes nightly, the spreadsheet carries on, and differences between the two are explained tank by tank
Go-live
One region first, then the network, with a threshold review after the first full month
A quick win at department scale. Effort depends on how reachable the gauge readings are (central system versus per-station exports), how many data formats the tills produce, and whether ERP deliveries carry a time of receipt.
Tank three has been losing a hundred litres a week since August. The spreadsheet noticed in October.
Send us one station’s month: gauge readings, daily sales and deliveries. We return that month’s daily balance computed by our rule, the differences that would have needed a decision, and a first classification of each.
Send one station’s month of balancesThe neighbouring process usually has the same problem
Invoice litres, delivery-note litres and tank litres can be three different numbers. Temperature and time make the difference.
See the solution Finance & accountingEvery station’s takings reconciled each morningTills, terminals, cash and the courier line up by themselves; people see only the exceptions.
See the solution Finance & accountingThree-way match exceptions resolved before the payment runThree documents, three numbers, and an invoice waiting for someone to find the fourth.
See the solution