
SAP and Esker Invoice Integration for a Luxury Fashion House
- Client
- Luxury fashion · Italy · part of a global luxury group, seven sister companies in the process
- Industry
- Retail & E-commerce
- Department
- Finance & Accounting
- Region
- Italy · Europe
Every intercompany invoice had to be registered twice, posted in SAP and linked in Esker, with an accountant copying dates, numbers and amounts between the two for every invoice from seven sister companies. We built a UiPath robot that matches the invoices across both platforms, posts them in SAP and links them back in Esker, designed to cut processing time by 80%.
A working model of the approach on sample data. It plays on its own and pauses when scrolled away; nothing here touches a live system.
The results
- 7
- sister companies in one routine
- Each with its own supplier, VAT code and document type in the robot's configuration.
- ~25 min
- manual baseline per run
- 24 min 54 s, 155 actions across 17 windows, recorded before the build.
- 80%
- target cut in processing time Projected
- Design target from the process definition, not a measured result.
The challenge
Our client is an Italian luxury fashion house within a global luxury group. Intercompany invoices from seven sister companies across Europe arrive in Esker, the cloud platform the group uses to receive supplier invoices, and wait in an intercompany verification queue. Each one had to be found in SAP, posted there, and then linked back to its SAP document in Esker, by hand.
The manual baseline recorded in the process definition before the build: 24 minutes 54 seconds per run, 155 actions, 96 mouse clicks and 152 key presses across 17 windows in 4 applications.
What it was costing them
- Double keying. Invoice date, number, amount and order reference copied from one system to the other for every invoice.
- Matching by eye. The only value common to both systems is the amount, so matching was manual and error-prone.
- Seven companies, one routine. The same steps repeated for every sister company, each with its own supplier code, VAT code and document type.
- Unlinked invoices. An invoice posted in SAP but not linked in Esker stays open in Esker, inflating the queue and the month-end reconciliation.
- Time. About 25 minutes of clicking and typing per recorded run.
- Invoice waits in Esker
- Found in SAP by amount
- Keyed into SAP
- Linked back in Esker
The approach
We built a UiPath robot that works SAP and Esker side by side: it pulls the open items from SAP, matches them to the invoices waiting in Esker, posts each invoice in SAP and links it back in Esker.
From open item to linked invoice
- SAP open items extracted. The robot runs the SAP general-ledger line-item report (FBL3N) for the intercompany account, sorts it by partner company and exports it.
- Per-company loop. For each sister company, driven by a configuration file the process owner maintains (supplier, partner company, VAT code, document type), it filters Esker's intercompany queue and exports the invoices waiting.
- Matching. Each Esker invoice is matched to its SAP open item by amount; unmatched invoices are logged and skipped.
- Posting in SAP. The robot enters the invoice in SAP invoice verification (MIRO): date, invoice number, amount, purchase-order reference, VAT code and document type, then simulates and posts.
- Linking in Esker. It finds the new SAP document number in the vendor line-item report (FBL1N), switches the Esker invoice's ERP from the legacy system to SAP and links the invoice to the SAP document.
- Reports and notifications. Daily Excel reports per company, exception logs, and a recap email to the process owner at the end of each run.
- SAP open items
- Esker queue per company
- Match by amount
- Post in SAP
- Link in Esker
- Reports to process owner
Safe by design
- Demo and highlight modes let the team test the full run without posting or linking anything.
- The final post and link steps run only in production mode.
- Attended robot on the accountant's machine, with credentials from Windows Credential Manager; no Orchestrator needed.
- The company list, supplier codes, VAT codes and document types live in a configuration file finance owns, not in code.
Technology
| Layer | What we used |
|---|---|
| Automation | UiPath Studio, Robotic Enterprise Framework, attended robot |
| ERP | SAP GUI automation with Deefinity SAP activities (FBL3N, FBL1N, MIRO) |
| Invoice platform | Esker cloud accounts payable, via UiPath UI Automation in Chrome |
| Configuration and reports | Excel configuration file, daily Excel reports per company |
| Notifications and security | UiPath Mail activities, Windows Credential Manager |
The outcome
The accountant no longer copies an invoice from one system to the other: the robot is built to match it, post it in SAP and link it back in Esker, company by company, and to report what it could not match.
| Before | After | |
|---|---|---|
| Keying per invoice | Twice, in SAP and in Esker | Once, by the robot, from matched data |
| Matching SAP to Esker | By eye, on the amount | Automatic, logged when there is no match |
| Seven sister companies | Same routine repeated by hand | One loop driven by a configuration file |
| Linking back in Esker | Manual, easy to miss | Done by the robot after every posting |
| Time per run | ~25 minutes of clicks and keystrokes | Designed for an 80% cut |
- Intercompany invoices from seven sister companies matched, posted in SAP and linked in Esker by one robot.
- Designed to cut processing time per invoice by 80% against a manual baseline of about 25 minutes per run. Measured savings were not recorded.
- Every run reported per company, with unmatched invoices logged for follow-up.
- No integration project. Two finance platforms joined in months by a robot working the same screens the accountant used.
The risk most teams miss
When two finance systems share only one field, the amount, a naive match will pair the wrong invoices the first time two invoices have the same value. The robot processes company by company, oldest first, logs anything it cannot match, and keeps SAP posting and Esker linking behind a simulate step and production-only switches, so a wrong match is caught before it becomes a wrong entry in the books.
Built with
The tools this ran on, by the layer each one carried.
- Apps & integration
- Automation
- Data & cloud
Next step
Start the same conversation
Tell us the process that keeps breaking. We will come back with what it would take to fix it, what it would cost, and what we would measure.
Or write to us directly: •••••@•••••••.•••
- A reply from a partner within one business day
- Fixed scope and fixed fee, agreed before we start
- The maps and the backlog are yours either way






