Meylan Technologies & ConsultingOn most French e-invoicing projects, the tax and functional teams do the bulk of the work: picking a Plateforme Agréée, mapping formats, testing the directory. Security is brought in late, with a fixed go-live date and a request to "just build the role".
The role deserves more attention than that. DRC objects are rarely restricted properly, and a France role built from the SU24 proposal with everything at asterisk gives a French user access to the electronic documents of Italy, Spain, Poland and any other country DRC runs in the same system. Below is the footprint and how we would cut it.
Transactions and apps
DRC has one classic transaction and three Fiori apps.
EDOC_COCKPIT, the eDocument Cockpit, is where users do most of the work: display electronic documents, submit them, create the ones that failed to generate, monitor status and run follow-up actions.
The three Fiori apps do different things:
| Fiori ID | App | Semantic object and action | UI5 component |
|---|---|---|---|
| F4306 | Manage Electronic Documents | ElectronicDocument-documentComplianceCockpit | glo.log.dccockpits1 |
| F5218 | Manage Document and Reporting Compliance | GlobalCompliance-overview | gs.gco.dashboard.s1 |
| F1515 | Run Statutory Reports | ReportingTask-run | gs.fin.runstatutoryreports.s1 |
F4306 is the Fiori version of EDOC_COCKPIT. F5218 is the compliance dashboard, an overview across countries and processes. F1515 is the statutory reporting runtime, which covers e-reporting rather than e-invoicing.
The role menu also needs these OData services:
EDOC_DCC_SRV(the cockpit)SRF_REPORTING_TASK(statutory reporting)CV_ATTACHMENT_SRV(attachments)CA_OC_OUTPUT_REQUEST_SRV(output management)CA_FM_FEATURE_TOGGLE_STATUS_SRV
On S/4HANA with Fiori, maintaining SU24 for EDOC_COCKPIT alone is not enough. The proposal has to be on the IAM app or the OData service. Otherwise the tile authorizations come out wrong, and go-live week is spent chasing 403 errors that look like application bugs.
Three ways to restrict access
DRC has three independent restriction dimensions. It helps to be clear early on which one does what.
1. Process: EDO_PROC
The EDO_PROC authorization object has two fields:
EDO_PROC, the eDocument processEDO_PRSTEP, the process step
The France split happens at process level. Outbound customer invoices, inbound supplier invoices and the e-reporting flows are separate processes with separate values, which matches how finance teams are usually organised: AR bills, AP receives, tax reports. A billing clerk has no reason to resubmit a supplier invoice to the platform, and the reverse is also true.
EDO_PRSTEP controls which step of the process lifecycle the user can act on. This is the field that separates viewing a document from sending it to the platform or cancelling it. In most roles we review it is set to asterisk, so anyone who can open the cockpit can perform every action the process supports.
2. Sensitivity or grouping: EDO_ORG
EDO_ORG has three fields:
EDO_ORG, the organizational criterionEDO_ORGVAL, the value of that criterionEDO_PROC, the process again
This dimension is extensible. You define in customizing what the organizational criterion represents (sales organization, plant, document category, invoice sensitivity class, or whatever the business needs to separate) and then restrict on its values. The India localisation has its own version, EDOIN_ORG1, where org units group plants and are mapped to company codes in a Customizing view before PFCG offers the values.
Two practical points. The values must exist in customizing before PFCG shows them, so this depends on the functional team and security cannot deliver it alone. And because EDO_PROC is also a field of this object, the process restriction is checked twice, once in EDO_PROC and once in EDO_ORG.
3. Company code: EDO_BUK
EDO_BUK has a single field, BUKRS, the standard company code org level. It is what keeps the French role from displaying Italian SdI traffic.
Next to it, F_SRF_RNTM controls the statutory reporting runtime with ACTVT, COUNTRY and SRF_REPCAT (report category). COUNTRY is an org level and should be FR, and only FR, in a France role.
EDO_PROC and EDO_ORG are already org levels
EDO_PROC and EDO_ORG are delivered as organizational levels. On S/4HANA 2023 they appear in PFCG as $EDO_PROC and $EDO_ORG without any conversion.
We have had this discussion on several projects. If the team assumes these are ordinary authorization fields, it plans a PFCG_ORGFIELD_CREATE conversion: a client-independent change affecting every role in the system, with an impact analysis, a PFCG freeze, mass regeneration and a change record. That is a lot of disruption, and on a current release SAP has already done it.
Check AGR_1252 for your existing DRC roles, or open one in PFCG and click the org level button. If $EDO_PROC and $EDO_ORG are listed, skip the conversion and go straight to role derivation.
Having the org levels does not mean they are used. In the DRC roles we have reviewed, the derived roles carry a proper company code and country, and $EDO_PROC and $EDO_ORG are left at asterisk because nobody filled them in.
Connectivity objects
France works through approved platforms rather than a single government portal, and SAP connects to them over OAuth 2.0. That brings in an object most role designers have not dealt with.
S_OA2C_USE controls use of an OAuth 2.0 client. The end user needs:
OA2C_PROF=GCO_ECOM_OAUTH_PROFILE, the client profile that calls the service provider APIACTVT=16, for the token request
Restrict OA2C_PROF to that profile. Do not put an asterisk there, and do not move the object into a general Basis or catch-all role. The profile name is the only restriction the object offers; widen it and there is nothing left to control.
Before deciding which role gets it, find out whether the token is requested in the dialog user's context or by the technical user running EDOC_BACKGROUND. Often it is both, and the background user tends to be forgotten. Trace it with STAUTHTRACE in a sandbox instead of guessing.
Keep OAuth client configuration away from the users who submit documents. A user who can both reconfigure the OAuth client and submit can redirect invoice traffic elsewhere.
S_SERVICE also appears, with SRV_TYPE = HT and a list of hashed service names. The hashes are generated by SU24 maintenance on your own system, so generate them there rather than copying them from a template or a blog post.
Other objects in the role
A full DRC France role has around forty objects. Most come from the SU24 proposal and need no particular attention. Three groups do.
The financial drill-down objects (F_BKPF_BUK, F_KNA1_BUK, F_LFA1_BEK and similar) are checked when the user jumps from the cockpit to the source billing or accounting document. Without them the cockpit only partly works, and the first week produces tickets that look like DRC problems but are not.
EDOIN_ORG1 is the India localisation object and comes into a France role through the SU24 proposal. Remove it rather than leaving it at asterisk.
AIF: rejected invoices end up in the Application Interface Framework as well as in the cockpit. Whoever corrects them needs /AIF/ authorizations restricted to the relevant namespace and interfaces. This is a second console with its own design, and teams usually discover it the first time a batch fails.
Segregation of duties
In the French model, invoice lifecycle statuses are sent back to the administration. Suppressing or changing a status therefore alters reported data, not only an internal record, and the cockpit actions carry more risk than they would in a purely internal process.
Four conflicts to add to the ruleset before go-live:
- Create customer invoice (VF01) with cockpit actions that cancel, ignore or manually complete an eDocument. The same person can invoice and then keep the invoice from reaching the platform.
- Post supplier invoice (MIRO) with setting the inbound lifecycle status. Accepting or refusing an invoice on behalf of the company is a business decision.
- Maintain DRC customizing in production with submit.
- Maintain the OAuth client configuration with submit.
Standard rulesets predate the mandate and contain none of these. In SAP GRC Access Control they have to be built as custom functions and risks; in our tool, MTC Skopos, they are added to the ruleset file. In both cases someone has to own the work before September.
Role model
We use three master roles, split by process, because each has its own menu, drill-down targets and owner:
- Outbound (customer invoices), owned by AR and billing
- Inbound (supplier invoices and lifecycle responses), owned by AP
- E-reporting (transaction and payment data), owned by tax or treasury
Derive them on company code and country, with $EDO_PROC fixed in the master and $EDO_ORG holding whatever grouping the business asked for. Separate display from action inside each master with EDO_PRSTEP instead of adding another derivation dimension. Sensitivity requirements are usually about who can act, not who can see; settling that question early avoids a large number of derived roles.
The payment data part of e-reporting is often left out of scope. It belongs to neither AR nor AP, it has the same September deadline, and it needs an owner.
If you are reading this in August 2026
Time is short, and converting org levels in roles that are already productive takes more than two weeks. On a current release you will almost certainly not need to.
What you do need is to check the values of $EDO_PROC and $EDO_ORG in your existing DRC roles. If they are at asterisk, every user with the cockpit can see and act on every electronic document in the system, which an auditor will report. The check takes about fifteen minutes.
In order of priority:
- Open
AGR_1252for your DRC roles and confirm that$EDO_PROCand$EDO_ORGare org levels with real values, not asterisk. - Confirm that
EDO_BUKandF_SRF_RNTM-COUNTRYare derived per country, so the France role cannot read Italian or Spanish traffic. - List every role holding
S_OA2C_USEand check thatOA2C_PROFis restricted, including for the background user behindEDOC_BACKGROUND. - Trace the cockpit end to end in a sandbox with STAUTHTRACE, including the drill-down to billing and accounting documents.
- Write the four SoD rules above and run them against the roles you are about to release.
How MTC helps
From Geneva, we design and review SAP authorization concepts for regulated, multi-country SAP systems. For the French mandate this covers:
- process and company-code restriction in DRC
- derived-role models
- OAuth and interface exposure
- SU24 alignment for Fiori
- SoD rules that standard content does not include
On large programs we work alongside leading global audit, risk and technology consulting firms, with a senior Swiss-based team responsible for the security work.
Related reading
- SAP Security Consulting, our full SAP security scope
- SAP GRC Access Control: What It Is and When You Need It
- SAP Firefighter Role Design: Best Practices for Emergency Access
- S/4HANA Migration: Greenfield vs Brownfield vs Selective
- IT General Controls (ITGC): A Practical Guide for Audit Readiness
Frequently Asked Questions
Which authorization objects does SAP DRC use?
The core objects are EDO_PROC (eDocument process and process step), EDO_ORG (an extensible organizational criterion, its value and the process), EDO_BUK (company code) and F_SRF_RNTM (statutory reporting runtime: activity, country, report category). Add S_OA2C_USE for the OAuth 2.0 client, S_SERVICE for the Fiori/OData services, and the financial drill-down objects (F_BKPF_BUK, F_KNA1_BUK, F_LFA1_BEK) checked when a user jumps from the eDocument Cockpit to the source document. A complete France role has around forty objects.
Do I need PFCG_ORGFIELD_CREATE to make EDO_PROC and EDO_ORG organizational levels?
Not on current S/4HANA releases. EDO_PROC and EDO_ORG are delivered as organizational levels and appear in PFCG as $EDO_PROC and $EDO_ORG. PFCG_ORGFIELD_CREATE is a client-independent change that affects every role and needs an impact analysis, a PFCG freeze and mass regeneration, so check AGR_1252 or the org-level button on an existing DRC role first. Being an org level does not mean the value is restricted: most derived roles we see carry a company code and a country, with $EDO_PROC and $EDO_ORG left at asterisk.
When does the French e-invoicing mandate start?
From 1 September 2026, every VAT-registered business established in France must be able to receive structured electronic invoices through an approved platform, and large companies and ETI must also issue them. SMEs and micro-enterprises have until 1 September 2027 to start issuing. E-reporting (B2C and international transaction data, plus payment data) follows the same calendar.
Which SAP Fiori apps cover Document and Reporting Compliance?
Three apps, each with a different purpose: F4306 Manage Electronic Documents (the Fiori equivalent of EDOC_COCKPIT), F5218 Manage Document and Reporting Compliance (cross-country compliance dashboard) and F1515 Run Statutory Reports (statutory reporting runtime, used for e-reporting). The role menu also needs the OData services EDOC_DCC_SRV, SRF_REPORTING_TASK, CV_ATTACHMENT_SRV, CA_OC_OUTPUT_REQUEST_SRV and CA_FM_FEATURE_TOGGLE_STATUS_SRV.
What SoD conflicts should be added for French e-invoicing?
Standard rulesets predate the mandate, so four conflicts have to be written by hand: create customer invoice (VF01) with cockpit actions that cancel, ignore or manually complete an eDocument; post supplier invoice (MIRO) with setting the inbound lifecycle status; DRC customizing in production with submit; OAuth client configuration with submit. The French model sends invoice lifecycle statuses to the administration, so suppressing or altering a status changes reported data.