All case studies & publications

Retail & E-commerce

SAP and Esker Invoice Integration for a Luxury Fashion House

Anonymised engagement
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.
One intercompany invoice, handled twice
  • Invoice waits in Esker
  • Found in SAP by amount
  • Keyed into SAP
  • Linked back in Esker
The amount is the only value both systems share.

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

  1. 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.
  2. 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.
  3. Matching. Each Esker invoice is matched to its SAP open item by amount; unmatched invoices are logged and skipped.
  4. 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.
  5. 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.
  6. 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 and Esker, side by side
  • 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

LayerWhat we used
AutomationUiPath Studio, Robotic Enterprise Framework, attended robot
ERPSAP GUI automation with Deefinity SAP activities (FBL3N, FBL1N, MIRO)
Invoice platformEsker cloud accounts payable, via UiPath UI Automation in Chrome
Configuration and reportsExcel configuration file, daily Excel reports per company
Notifications and securityUiPath 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.

BeforeAfter
Keying per invoiceTwice, in SAP and in EskerOnce, by the robot, from matched data
Matching SAP to EskerBy eye, on the amountAutomatic, logged when there is no match
Seven sister companiesSame routine repeated by handOne loop driven by a configuration file
Linking back in EskerManual, easy to missDone by the robot after every posting
Time per run~25 minutes of clicks and keystrokesDesigned 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.

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