Home · Solutions · Legal & compliance · Compulsory stocks calculated, the declaration awaits a signature
Solution · Legal & complianceThe stock level computed daily rather than reconstructed at month-end from spreadsheets
Compulsory stocks calculated, the declaration awaits a signature
Every day a robot lines up imports and production from the ERP, own and operator-held stocks, computes the required and actual level with a period-end forecast, and prepares the declarations and the fee calculation for approval.
Executive summary
The stockholding obligation moves with import and production volumes, and the inputs sit in three places: the ERP, the warehouses and ticket agreements. They are computed once, at declaration time.
The required and actual level is computed daily, with a period-end forecast. The margin stops being a spreadsheet surprise.
A margin crossing the warning threshold triggers an alert weeks ahead, while the answer is still a ticket agreement rather than an explanation. Declarations and the fee reduce to one approval.
imports and production in the ERP; own and operator warehouse stocks; ticket agreements; the margin board and declarations in Microsoft Teams
Business problem
An obligation that drifts
The stockholding law ties the size of the obligation to the company’s activity: imports and production in reference periods. A growing company has a growing obligation; a seasonal one has an obligation that swings. The required level is not a constant but a function of data that changes daily.
The coverage side is just as mobile: part of the stock sits in own tanks, part with depot operators under ticket agreements, each with its own terms and volumes. The actual level is a sum of balances from several systems and several contracts, each updating at its own rhythm.
In practice both ends of the equation meet once: at the declaration. Someone collects balances, someone computes the base, someone fills the form and pays the stockholding fee. Between declarations the company lives on the assumption that the margin is safe, because it recently was.
That assumption is expensive in both directions. Too small a margin is regulatory risk with sanctions nobody wants to discuss over coffee. Too large a margin, kept “just in case”, is frozen capital and storage fees nobody has priced, because fear has no budget line.
How it works today
Below is what the work looks like before anything is automated.
- PersonAs the declaration nears, someone asks warehouses and operators for day-stamped balances
- PersonThe obligation base is computed in a spreadsheet from ERP import and production exports
- Risk of errorTicket agreements enter the coverage from memory: which applies, for how much, until when
- WaitingThe calculation happens once a period, so margin drift between declarations is invisible
- Risk of errorThe safety buffer is set by intuition, usually generously, because nobody sees the daily curve
- Risk of errorWhen business volumes change, nobody recomputes the obligation until the calendar demands it
Why the current process costs more than it appears
The bill that never shows up in a budget.
- Capital frozen in an oversized buffer: every percentage point of “gut-feel” margin is physical tonnes of fuel, financed and stored for money.
- Ticket agreements renewed in a hurry because the deadline arrived suddenly: the company’s negotiating position is worst exactly when the need is urgent.
- The risk of the day when the margin was negative and nobody knew, because the spreadsheet was computed three weeks later.
- People’s time spent gluing balances from three sources at every declaration, in a rhythm that makes management impossible, because the data is always historical.
Cost of inaction
The first row is usually the largest and the least visible: a “just in case” buffer appears in no report as the cost of fear, which is what it is. Its size in the model is illustrative; yours follows from the daily margin curve nobody draws today.
The third row deliberately has no amount: the consequences of a stock shortfall are set by statute and authority practice, not by a web page. It is enough to note that the only real protection is knowing about the problem before it happens.
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 mid-sized fuel producer and importer: an own depot with six tanks, two ticket agreements with operators, SAP as the ERP, Microsoft 365, stock obligations run by finance together with logistics.
Imports and production around 180k tonnes a year, an obligation computed from a moving base, declarations and the stockholding fee on the statutory rhythm.
Balances collected by email on declaration day, the base computed in a spreadsheet, the safety buffer held by intuition at the same level for years.
Nobody knows the daily margin; when business volumes shift, the obligation recount lags by weeks, and ticket agreement decisions are made under deadline pressure.
The robot computes the base from the ERP daily, collects own and operator balances, overlays the current ticket agreements from the register and draws the margin curve with a forecast; declarations and the fee are produced from the same data for approval.
In the modelled case the buffer drops from intuitive to computed, and ticket negotiations start a month early, because the forecast shows the threshold crossing in advance. Model numbers, not anyone’s ledgers.
Proposed solution
We start by writing down the obligation model: how your base is computed (imports, production, reference periods, exclusions), where the stock physically sits and which ticket agreements count towards coverage. The model has a finance-side owner and versions, because laws and contracts change.
Daily, the robot pulls volumes from the ERP, balances from own tanks and operator reports, updates coverage with the agreements in force and computes three numbers: required level, actual level and margin, with a period-end forecast at the current activity profile. The result lands on a Power BI board, and a warning-threshold crossing raises a Teams alert with weeks of lead time, not hours.
Declarations and the stockholding fee calculation are produced from the same data the board shows, so there is no second, “declaration” world computed separately. A person reviews, approves and files; the archive keeps every day with full lineage: which balances, which agreement, which model version.
UiPath Orchestrator: daily runs, data-source queues, retries and an audit trail; UiPath Integration Service connectors for Microsoft Teams and Outlook 365; UiPath Action Center approvals; a Microsoft Power BI board on a Teams channel
The versioned obligation model and the ticket agreement register, a daily three-number calculation with forecast, warning thresholds with alerts, declarations and the fee from one data source, and a daily archive
Import and production volumes from SAP; tank balances from the depot system; operator stock reports (email, portal or file); the ticket agreement register with terms
How the automated process works
- AutomationDaily, the robot pulls ERP volumes plus own and operator balances
- AutomationThe obligation base and coverage are computed by the versioned model with the agreement register
- SystemThe margin curve with forecast updates on the board; every day is archived with lineage
- AutomationA warning-threshold crossing raises a Microsoft Teams alert weeks in advance
- PersonFinance decides: a ticket agreement, a stock transfer or an import plan correction
- PersonThe declaration and the fee, built from the same data, wait for a single approval
Human-in-the-loop model
Automation handles
- The daily calculation of required and actual levels and the margin with forecast
- Watching ticket agreement terms and warning thresholds, with alerts
- Preparing declarations and the fee calculation with full data lineage
People decide
- The obligation model, warning thresholds and every exception to the rule
- Coverage decisions: ticket agreements, transfers, the import plan
- Approval and filing of every declaration, and contact with the institutions
Before and after
Systems and integrations
The stack is short on purpose: one engine, one execution layer, one place where a person decides.
Inputs
- import and production volumes in the ERP
- own tank balances
- depot operators’ stock reports
- the ticket agreement register and the versioned obligation model
Automation layer
- UiPath Orchestrator
- UiPath Robots
- UiPath Integration Service
- UiPath Action Center
Target systems
- the daily margin curve in Power BI
- threshold alerts in Microsoft Teams
- declarations and the fee calculation for approval
Human touchpoints: UiPath Action Center alerts and approvals in Microsoft Teams; the margin board as a Teams tab; a model review at every change of law or contracts
Technologies used
daily runs, source queues, retries, credential store, audit
Aoperator reports picked from email, alerts and approvals on finance channels
Adeclaration and coverage approvals where finance already works
Athe margin curve, the forecast, the daily archive with lineage
Athe base, fee rates and deadlines follow from the stockholding act and secondary legislation; the legal state is verified at implementation and at every change
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.
Industry
Case studies
Delivered client work is described under Case studies.
Illustrative economic model
Numbers you can check against your own data.
The model shows a mechanism, not a promise: how far the buffer can drop is told only by your daily margin curve, which does not exist today. The opposite happens too: the curve shows days when the intuitive buffer was too small, and then the value is not a saving but an avoided conversation with the regulator. Capital and storage rates belong to the scenario.
Run the numbers on your data
An illustrative estimate based on your inputs. It models freed capacity, not promised savings.
Business benefits
- The margin is a daily known quantity, not something reconstructed at declaration time
- The safety buffer follows from the curve and the cost of capital, not from fear
- Ticket agreements are negotiated in advance, on a forecast, not under deadline pressure
- Declarations and the fee come from the same data as the board, so there are no two truths
- Every day has an archive with lineage: balances, agreements, model version
The management view
- The regulatory risk of a negative-margin day shrinks to the risk of an unread alert
- Capital in stocks works by arithmetic, not by habit
- Management sees one curve instead of three spreadsheets and knows when the next coverage decision falls due
Board-level KPIs
daily margin against the threshold · days from alert to coverage decision · cost of buffer above the requirement · declarations filed before the deadline · operator balance gaps against agreements
Security and governance
The automation has exactly the permissions it needs. Not one more.
- The robot reads the ERP and warehouse systems with a minimal-rights technical account; declarations are filed by a person, or by the robot after approval
- Every day archives source balances, agreements in force and the model version, so every number can be traced back
- The obligation model and the agreement register are versioned; changes require the finance-side owner
- No personal data is involved; the calculations deal in volumes, tanks and contracts
- Boards and archives stay in your Microsoft 365 tenant, and the robots run in the EU region of UiPath Automation Cloud
Why now
Market volatility has moved into volumes: imports swing, and the obligation base with them. A once-a-period calculation was tolerable for a stable business; for a volatile one it is guessing.
The cost of capital stopped being free. A “just in case” buffer that hurt nobody at low rates now has a concrete, computable yearly price.
All the inputs already exist in systems: this is automation that assembles existing numbers into one curve, not a project to collect new data.
Relevant executive roles
The margin and the buffer become quantities managed by arithmetic, with a curve instead of a conviction
Ticket agreement and transfer decisions are made on a forecast, with weeks to spare
The declaration stops being a research project; it is the approval of data seen daily
Common questions and objections
Then the implementation is cheaper and the value shifts to the buffer: with a stable obligation the curve will quickly show how much margin you hold above need and what it costs a year. Stability is an argument for computing, not against.
The curve is as good as its slowest source, and we show that honestly: operator balances carry their report date, and uncertainty between reports is marked. More frequent reporting is often a matter of asking or an annex; many operators share weekly balances when the client requests it.
As it should be: we write the obligation model to your lawyers’ interpretation and automate only that. The robot computes faster but interprets nothing; every change of interpretation is a new model version with a date.
When this is not the right solution
- An obligation fully covered by one standing ticket agreement at stable volume: a renewal calendar will do
- An entity exempt from the obligation or below the statutory thresholds: there is nothing to compute
- No internal agreement on interpreting the base: legal alignment first, automation second
A question for the next management meeting
What was our lowest daily stock margin last quarter, and how do we know, given that we compute the level once a period?
Implementation approach
Scope without ambiguity, before anything is signed.
We deliver
- A versioned obligation model written to your lawyers’ interpretation
- The daily three-number calculation with forecast and the curve on a Power BI board
- The ticket agreement register with terms and renewal alerts
- Declarations and the fee calculation from one data source, approved in Teams
- A daily archive with full lineage, and a parallel run through one declaration period
We need from you
- The last two declarations with the spreadsheets they came from
- The ticket agreement register and access to operator stock reports
- A finance-side model owner and your lawyers’ interpretation of the base
Stages
Discovery
The last two declarations reconstructed from source data; a map of balance sources and their rhythms
Rules
The obligation model, warning thresholds and coverage principles approved by finance
Build
Collectors, the daily calculation, the curve with forecast, alerts, declarations and the archive
Parallel run
One full period: the robot computes daily, the declaration is made the old way, differences explained to the tonne
Go-live
Switch to a single data source for board and declarations, threshold review after a quarter
Effort depends mostly on the rhythm and form of operator reports and on whether the base interpretation is settled internally; the technical layer itself is simple.
The margin was negative for four days in February. March’s declaration came out fine, so nobody ever knew.
Send us your last two declarations with their source spreadsheets. We return the daily margin curve for that period computed by our model, the days that would have triggered an alert, and an estimate of how much buffer could be computed instead of assumed.
Check your margin against our rulesThe neighbouring process usually has the same problem
The twentieth of the month stops being panic day for the licensing desk.
See the solution Legal & complianceExcise movements closed on time, duty under controlNo electronic delivery document waits for its report of receipt until the last day.
See the solution Operations & productionTanks reconciled nightly, losses visible by morningThe gauges say one thing, the tills another. A daily balance says why.
See the solution