Skip to content

Four-eyes approval for ERP data changes

Four-eyes approval (the four-eyes principle) is a control under which a second, named person approves a data change, or its execution in the target system, independently of the person who prepared it. For ERP master-data changes it is implemented as a role-based workflow — requester, data owner, validator, executor, admin — where nothing is posted without an approval that carries a user and a time, and where validation and a dry run happen before the approver ever sees the request.

Updated · Visehub

Definition

Four-eyes approval — the four-eyes principle, or dual control — requires that a second, named person approves a change independently of the person who prepared it before it takes effect. In ERP data operations it applies to mass changes: a price update across a thousand materials, a vendor master change for a country, a reorganisation of plant-maintenance objects. These changes are reversible only on paper, and a single person with a script and production access is how most data incidents start.

Why mass changes need it more than transactions do

A single transaction has SAP’s own checks, a screen and an operator who sees what they enter. A mass change is prepared in a file, by someone who cannot see a thousand records at once, and executed by a program. The control that transactions get from the user interface has to be rebuilt as a process: validate the file against reference data and business rules, simulate the posting, let a named owner approve the exact records, execute through standard interfaces, and keep the audit trail.

How it is implemented without slowing teams down

StepWhat happensWhy it keeps the approval fast
RequestBusiness user fills a standardised Excel templateThe approver sees structured data, not free text
ValidateRules: required fields, allowed values, cross-field dependencies, duplicates, referencesBad requests are rejected before anyone approves anything
SimulateDry run through the real interface (BAPI, IDoc, OData)The approver approves a result, not a hope
ApproveRole-based: requester, data owner, validator, executor, adminSeparate people, separate roles, a name and a time on each decision
ExecuteControlled posting, batching, monitoring, rollback readinessNothing is written directly to tables; SAP’s checks stay active
AuditSource file, submitter, validation, approvals, status, system responsesThe package an auditor asks for is a by-product

This is the model vise Data Run implements, in production across the operating companies of a global brewing group, and the way five SAP PM object groups are governed across more than ten European markets in the plant-maintenance case.

Beyond compliance

Four-eyes approval is often introduced for audit reasons and kept for operational ones: it is the step that makes business users able to prepare their own changes safely, which is what removes IT from the critical path.

Frequently asked

01
Doesn't four-eyes approval slow everything down?
It slows down approvals of bad requests — which is the point. With validation and a dry run before the approval step, the approver sees a request that already passed the rules and the simulation; the decision takes a minute, not a review of a spreadsheet.
02
Who should approve?
The data owner of the object (finance for cost centres and accounts, procurement for vendors, maintenance for equipment), not IT. Execution can be a separate role so the person who posts is not the person who approved.
03
What does an auditor want to see?
For every change: the source file, who submitted it, the validation result, who approved it and when, the execution status and the system's response. If that package is produced automatically, audits take hours instead of weeks.
04
Is a ServiceNow ticket enough?
A ticket records that someone asked. Four-eyes approval on the data change records that someone with authority confirmed the exact records being posted — after validation. You keep the ticket; the control sits after it.

Related