Home · Solutions · Supply chain
Solution · Supply chainEvery night a robot compares every location and batch; people count only where it matters
Inventory that agrees: WMS and ERP reconciled every night
WMS and SAP stock are compared line by line every night, each difference is classified by cause, and warehouse leads see only what needs a count or an approved adjustment.
Executive summary
Stop discovering at the cycle count, or when an order cannot ship, that the WMS and the ERP disagree.
The reconciliation engine we build runs unattended on the UiPath Platform, with Microsoft Teams as the only interface most people see.
Differences are known the next morning, per bin and batch, instead of the following Wednesday from a Friday extract.
SAP S/4HANA (physical-inventory postings); WMS adjustment function; reconciliation register (SQL)
Business problem
Inventory control
The WMS knows bins, pallets, batches and tasks; the ERP knows stock per storage location, its value, the client's ownership, storage billing and what can be promised. Between them runs an interface that fails a little every day: a movement rejected on one side, a pallet factor of 48 cases here and 50 there, a quarantine zone with no equivalent storage location. None of these errors is large; together they let the two stock pictures drift apart, quietly, every day.
Those who feel it rarely caused it. Warehouse leads count pallets that were never missing. Customer service promises stock only the ledger has, then handles the short delivery. Finance meets the write-off at the annual count and cannot tell losses from corrections of corrections. The client disputes the monthly statement and quotes the stock-accuracy clause. Inaccuracy itself is normal: in a much-cited 2008 study of a US retailer (DeHoratius and Raman, Management Science), 65% of roughly 370,000 inventory records disagreed with the physical count. What separates a controlled operation is how fast differences are found and whether their cause is known.
How it works today
- PersonOn Friday the inventory controller exports WMS stock by bin and batch and SAP stock by storage location into one workbook per warehouse and pairs them with a lookup
- WaitingBoth extracts are already stale: receipts, picks and transfers since the export look like differences until the interface catches up on Monday
- PersonEach remaining line is investigated by hand: WMS movement history, SAP material documents, the IDoc monitor, an email to the warehouse lead asking for a recount
- WaitingRecount requests sit behind the day's shipments; answers arrive by Wednesday, often as a total without bin or batch
- SystemConfirmed differences are posted in SAP with whatever reason code the controller has time for; the warehouse office adjusts the WMS separately, sometimes in the opposite direction
- Risk of errorInterface failures and unit-of-measure errors are corrected line by line, never as a cause, so the same differences return next Friday and the year-end count carries the write-off
Why the current process costs more than it appears
The most expensive part of this process has no cost line.
- Six minutes a line looks cheap until multiplied: 1,900 lines a week across six warehouses is the working month of about five people, mostly spent proving that a difference was a timing effect.
- Late discovery is where the money goes. A shortage found when the pick fails means a short delivery, a customer-service call and a credit note; found by a robot at two in the morning, it means one recount before the wave is released.
- Adjustments without a cause hide systemic errors: a wrong pallet factor produces the same difference every week and is "corrected" every week, in both systems, until someone notices that the corrections alternate in sign.
Cost of inaction
Every new client adds materials, batches and a stock-accuracy clause, and every new site adds a controller: the workbook does not get worse on its own, it gets more expensive as the business grows. The write-off at the annual count stays a surprise, the auditor's question about adjustments without a documented cause is answered from memory, and two controllers' judgement about which differences are harmless remains the only reason the process works.
A plausible organisation with realistic proportions. The figures are there to be recalculated on your data; they are not a client result.
A contract logistics operator with six warehouses in Poland, Czechia and Germany, 1,400 employees, FMCG and retail clients; one WMS across all sites, SAP S/4HANA as stock ledger and client-reporting system, Microsoft 365 E3, an inventory control team of seven.
About 1,900 discrepancy lines a week, 8,200 a month, across roughly 45,000 active material, location and batch combinations.
A Friday extract from both systems into one workbook per warehouse, a lookup, investigation line by line, recount requests by email, adjustments posted separately in SAP and in the WMS.
Around six minutes per line, most of it on differences that would have resolved themselves by Monday; recounts wait for the warehouse lead; the cause is written nowhere.
A nightly UiPath reconciliation per material, location and batch classifies each difference by rule (timing, interface, unit of measure, master data, physical), routes the first four kinds and sends the warehouse lead a Teams count list for the last; confirmed differences are approved in Teams and posted in SAP with a reason code; Power BI shows accuracy and causes per warehouse and client.
In the modelled case a person opens roughly one third of the 8,200 lines a month, a difference is known the next morning rather than the following Wednesday, and every adjustment carries a cause, a count and an approver. Illustrative figures, not a client result.
Proposed solution
The reconciliation engine we build runs unattended on the UiPath Platform, with Microsoft Teams as the only interface most people see. In each warehouse's quiet hour an Orchestrator time trigger starts the robot, which reads WMS stock by bin and batch through a read-only view and SAP stock by storage location, batch and stock type through the standard stock interface, at the same minute. Every difference becomes a queue item carrying both quantities, both units of measure and the WMS movements logged between the two timestamps: what the Friday workbook never has, and what lets a rule tell a pallet in transit from a pallet that is missing.
Rules run in a fixed order your controllers can read. Timing: a logged movement explains the quantity, so the line is parked and closed if it is gone the next night. Interface: an IDoc in error or a message that never left the WMS, listed with its reference for reprocessing. Unit of measure and master data: differing conversion factors, a material on one side only, a zone with no storage location, sent to the material master team. What remains is physical and goes to the warehouse lead as a Teams count list by six in the morning. Counts come back as UiPath Action Center tasks completed from Teams; the robot compares them with both systems and proposes an adjustment with a reason code from the list finance owns, to the controller within the value threshold and to finance above it. Approved lines are posted in SAP as physical-inventory differences with the reason code and task reference; the WMS is corrected through the vendor's API where one exists, otherwise by the warehouse office. No model guesses a cause; a rule assigns it, and every line, count, approval and SAP document number lands in a register that feeds Power BI.
UiPath Orchestrator time triggers, queues, folders and credential stores; UiPath unattended Robots; UiPath Integration Service connectors for Microsoft Teams and Microsoft OneDrive & SharePoint (Excel Online); UiPath Action Center tasks completed from Microsoft Teams; Power BI reports as a Teams tab
Comparison logic, classification rules and their precedence, the timing buffer from the movement log, the reconciliation register, count lists and adjustment proposals, approval thresholds and reason-code mapping, SAP posting logic, the Power BI model and reports, the runbook for inventory control
WMS stock snapshot, movement log and adjustment function through a read-only database view or the vendor's API; SAP S/4HANA stock and batch reads, IDoc status and physical-inventory postings through standard SAP interfaces (Material Stock OData API, physical-inventory BAPIs) run by an unattended robot inside your network
How the automated process works
- AutomationAt two in the morning an Orchestrator time trigger starts the run for each warehouse; the robot reads WMS and SAP stock at the same minute, by bin, storage location and batch
- AutomationEach difference becomes a queue item with both quantities, both units of measure and the movements logged in between; the rules classify it as timing, interface, unit of measure, master data or physical
- SystemTiming lines are parked for one night and closed if they disappear; interface lines are listed for reprocessing with the IDoc reference; master-data lines go to the material master team
- PersonBy six in the morning each warehouse lead has a count list in the Teams channel; counts and adjustment approvals come back as Action Center tasks from Teams, approvals from the controller or, above the threshold, from finance
- SystemApproved adjustments are posted in SAP as physical-inventory differences with the reason code; WMS corrections go through the vendor's API or to the warehouse office; everything lands in the register
- AutomationPower BI refreshes every morning: accuracy per warehouse and client, open lines by age and cause, adjustment value by reason code; a weekly summary goes to the inventory control channel
Human-in-the-loop model
Automation handles
- Snapshots, comparison and classification of every line, every night, for every warehouse
- Parking timing differences; listing interface failures with their reference
- Count lists, adjustment proposals with value and reason code, the register and the reports
People decide
- Warehouse leads count what the list asks for and record what they found, including damaged or mislabelled stock
- Controllers approve within their limit and pick the reason code where a rule cannot; finance approves above it and owns the reason-code list
- Master data and interface teams remove causes: conversion factors, missing materials, failed messages
Before and after
Systems and integrations
We do not add technology to make an architecture look serious. Every element below has a specific job in this process.
Inputs
- WMS stock by bin and batch
- WMS movement log
- SAP stock by storage location and batch
- SAP IDoc status
- material master conversion factors
Automation layer
- UiPath Orchestrator
- UiPath Robots
- UiPath Integration Service
- UiPath Action Center
Target systems
- SAP S/4HANA (physical-inventory postings)
- WMS adjustment function
- reconciliation register (SQL)
- Power BI semantic model
Human touchpoints: count lists and summaries in warehouse Teams channels; Action Center tasks in Teams; exception workbook on SharePoint; Power BI tab in Teams
Technologies used
nightly run per warehouse from a time trigger; queues hold every difference with category, evidence and outcome; folders, credential store, audit
Acount list and weekly summary in each warehouse channel, mentioning the lead; exception workbook in the channel's files
Acount confirmations and adjustment approvals as tasks completed from Teams
Aaccuracy per warehouse and client, open lines by cause and age, adjustment value by reason code
Astock and batch reads, IDoc status, physical-inventory postings with reason codes, through UiPath's SAP connectors and activities
Astock by bin and batch, movement log, adjustment function where the API allows it
CIllustrative economic model
What it is worth, with the arithmetic shown.
1,900 discrepancy lines a week across six warehouses, about 8,200 a month; six minutes of investigation per line; €22 as the fully loaded hourly cost of an inventory controller in Central Europe. Those inputs are ranges we see in inventory control teams, never a measurement at a client. For the after state we assume that around two thirds of lines are timing or interface effects the rules close or route without a person, so roughly one third still needs a count or a master-data decision. We show capacity released, not headcount removed.
Run the numbers on your data
An illustrative estimate from your own inputs. It models released capacity; it is not a promise of savings.
Business benefits
- Differences are known the next morning, per bin and batch, instead of the following Wednesday from a Friday extract
- People investigate only lines that need a person; timing and interface effects never reach the warehouse
- Short deliveries and failed picks caused by stock only the ledger has decline, because the ledger is corrected before the morning wave
- Every adjustment carries a reason code, a count and an approver, and systemic causes are fixed once instead of being corrected weekly
The management view
- Stock accuracy per warehouse and client becomes a number on Monday morning, not an argument at the quarterly business review
- Adjustment value by reason code and approver is visible before it reaches the profit and loss account as a write-off
- Segregation of duties is enforced by the flow, and a seventh warehouse or a new client is a configuration change, not a new controller
Board-level KPIs
Security and governance
Where the data sits and who can see it.
- The robot reads the WMS through a read-only account and posts in SAP with a dedicated service account limited to physical-inventory transactions; no personal login is reused
- Secrets live in Orchestrator's credential store, backed by Azure Key Vault or the vault you already run; folders and roles separate the warehouses; the tenant runs in the UiPath Automation Cloud EU region, and Teams, SharePoint and Power BI content stays in your Microsoft 365 tenant
- The lead who counts cannot approve, the controller cannot approve above the limit, and every line keeps its history: quantities, category, count, approver, SAP document number
Why now
Contract logistics agreements are renewed with a stock-accuracy KPI attached; an operator with a nightly reconciliation per client argues a disputed statement from evidence, the other side from a workbook
Waiting has a running cost: the modelled €18,040 a month of controller time, plus the short deliveries in between and the write-off that surfaces at the annual count
Nothing here waits for new technology: SAP exposes standard stock and physical-inventory interfaces, Orchestrator triggers and queues are mature, Action Center tasks are completed inside Teams, and no AI is involved, so there is no model to govern
Relevant executive roles
Failed picks and short deliveries from stock the ledger only thinks it has become visible and countable; the warehouse day starts with a list, not a workbook
Adjustments reach the books with a cause, a count and an approver; the annual count stops being the moment the write-off is discovered
Interface failures between the WMS and SAP are found the night they happen and reprocessed with a reference, not weeks later as a stock dispute
Common questions and objections
Usually it lists differences without causes and without the movements since the ERP cut-off, which is why people spend six minutes a line proving timing effects. We take it as one input; the value is in the classification, routing and posting with evidence.
It posts nothing without a count and an approval. Rules propose, people approve within limits finance sets, and every posting carries the approver's task reference.
An embedded WMS removes one interface and keeps the others: production, third-party sites, client systems, units of measure. The rules survive a migration; only the WMS connector changes.
When this is not the right solution
- Where a single warehouse produces fewer than a few hundred discrepancy lines a month, a good weekly report and disciplined counting are cheaper than a nightly robot
- Materials, locations or batches are modelled so differently in the two systems that no comparison key exists, or the interface fails so often that a reconciliation would only measure the failures; mapping or stabilising comes first
A question for the next management meeting
Of the stock differences between the warehouse system and the ERP that we adjusted last year, for how many do we know the cause, and what value did they carry?
Implementation approach
What we deliver, and what we need from you to start.
We deliver
- A sweep through three months of discrepancy history: causes, volumes per warehouse and client, the reason codes finance accepts
- Comparison logic for your WMS and SAP structures and the classification rules, written with your controllers
- Count lists and approvals in Teams, adjustment proposals, SAP posting with reason codes, the register and the reports
- A pilot in one warehouse, then rollout site by site with hypercare and a runbook for inventory control
We need from you
- Read access to WMS stock and movement data and to SAP stock, batch and IDoc status, for test and production
- A process owner in inventory control, one warehouse lead for the pilot, a finance owner for reason codes and thresholds
- Three months of past discrepancy workbooks with the adjustments posted for them
Stages
Discovery
Discrepancy history, causes, volumes, reason codes and thresholds with inventory control and finance
Design and build
Comparison keys, rules, approval matrix, security model; robots, integrations, Teams touchpoints and reports in your environment
Validation
Parallel run against the Friday workbooks for several weeks, count sampling, acceptance by the controllers
Go-live and optimisation
One warehouse first with hypercare, then the remaining sites; rule tuning and cause elimination with master data and interface teams
Departmental. Effort depends on the number of warehouses and WMS instances, how stock types and batches are modelled on each side, and whether the WMS offers an API for adjustments.
Friday's discrepancy list is investigated by hand, line by line, every week.
Send us one week of your reconciliation workbook, anonymised if you prefer, with the adjustments that followed. We return a cause breakdown and a one-page estimate of the lines a nightly robot would close without a person.
Diagnose one week of differencesThe neighbouring process usually has the same problem
Stop chasing price and quantity differences by email while supplier payments wait for weeks.
View solution Supply chainThe part is next door, not on a six-week backorderStop ordering from the importer what your other sites already hold, and stop missing the return window for the rest.
View solution Finance & accountingWarehouse work billed from what the warehouse actually didStorage, handling and value-added work are billed from a spreadsheet somebody rebuilds every month.
View solutionIndustries we deliver this in most oftenManufacturing & industryRetail & e‑commerce