SAP DRC and the French E-Invoicing Mandate: The Authorization Concept You Actually Need

From 1 September 2026, every VAT-registered business established in France has to be able to receive structured electronic invoices through an approved platform. Large companies and ETI have to issue them as well. SMEs and micro-enterprises get until 1 September 2027 for issuance. E-reporting, meaning transaction data for B2C and international sales plus payment data, follows the same calendar.

Most of the implementation effort goes to the tax and functional teams: choosing a Plateforme Agréée, mapping formats, testing the directory. Security usually arrives late, gets handed a go-live date, and is asked to "just build the role."

That role is more interesting than it looks. SAP Document and Reporting Compliance (DRC) ships with a set of authorization objects that almost nobody restricts properly, and two of them are already organizational levels out of the box. If you build the France role the lazy way, you give a French AP clerk visibility over every electronic document in every company code in the system, including Italy, Spain, Poland and anything else DRC is running.

Here is what the footprint actually looks like.

What the user touches

DRC has one classic transaction and three Fiori apps.

The transaction is EDOC_COCKPIT, the eDocument Cockpit. It is the workhorse: display electronic documents, submit them, create ones that failed to generate, monitor status, and perform follow-up actions.

On the Fiori side you are looking at three apps, and they are not interchangeable:

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 equivalent of EDOC_COCKPIT. F5218 is the compliance dashboard, an overview across countries and processes. F1515 is the statutory reporting runtime, which is where the e-reporting side lives rather than the e-invoicing side.

Behind those tiles sit the OData services you need in the role menu:

EDOC_DCC_SRV (the cockpit itself)
SRF_REPORTING_TASK (statutory reporting)
CV_ATTACHMENT_SRV (attachments)
CA_OC_OUTPUT_REQUEST_SRV (output management)
CA_FM_FEATURE_TOGGLE_STATUS_SRV

If you are on S/4HANA with Fiori, maintaining SU24 against EDOC_COCKPIT alone is not enough. The proposal has to sit on the IAM app or the OData service, or the tile authorizations come out wrong and you spend go-live week chasing 403s that look like application errors.

The three restriction dimensions

DRC gives you three independent ways to cut access. Understanding which one does what saves a lot of arguing later.

1. Process: EDO_PROC

The EDO_PROC authorization object has two fields:

EDO_PROC, the eDocument process
EDO_PRSTEP, the process step

The process is where the France split lives. Outbound customer invoices, inbound supplier invoices and the e-reporting flows are separate processes with separate values. That maps almost perfectly onto how finance teams are organised: AR bills, AP receives, tax reports. A billing clerk has no business resubmitting a supplier invoice to the platform, and vice versa.

EDO_PRSTEP is the finer cut. It controls which step of the process lifecycle the user can act on. This is the field that separates "can look at the document" from "can send it to the platform" from "can cancel it." Almost every role I see in the wild has this on asterisk, which means 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 criterion
EDO_ORGVAL, the value of that criterion
EDO_PROC, the process again

This is the extensible dimension. You define what the organizational criterion means in customizing, then restrict on its values. Sales organization, plant, document category, invoice sensitivity class, whatever your business needs to segregate. India's localisation has its own flavour of this in EDOIN_ORG1, where org units group plants and get mapped to company codes in a Customizing view before PFCG will offer the values.

Two things about EDO_ORG that catch people out. First, the values have to exist in customizing before PFCG shows them, which makes this a dependency on the functional stream, not something security can deliver alone. Second, EDO_PROC appears inside this object too, so the process restriction is enforced twice, through EDO_PROC and through EDO_ORG.

3. Company code: EDO_BUK

EDO_BUK carries a single field, BUKRS, and it is the standard company code organizational level. Nothing exotic here, but it is the one that stops your French role from displaying Italian SdI traffic.

Alongside it, F_SRF_RNTM governs the statutory reporting runtime with ACTVT, COUNTRY and SRF_REPCAT (report category). COUNTRY is an org level. For a France role this should be FR and nothing else.

The part most people miss

EDO_PROC and EDO_ORG are delivered as organizational levels. On S/4HANA 2023 they show up in PFCG as $EDO_PROC and $EDO_ORG with no conversion required.

I want to be blunt about why this matters, because I have had this conversation more than once: if you assume these are ordinary authorization fields, you plan a PFCG_ORGFIELD_CREATE conversion. That is a client-independent change affecting every role in the system, it needs an impact analysis, a PFCG freeze, mass regeneration and a change record. It is a genuinely disruptive piece of work. And on a current release it is completely unnecessary, because SAP already did it.

Check AGR_1252 for your existing DRC roles, or just open one in PFCG and look at the org level button. If $EDO_PROC and $EDO_ORG are there, skip the conversion entirely and go straight to role derivation.

Which leads to the second thing people miss. Being an org level does not mean the value is restricted. In every DRC role I have reviewed, the derived roles carry a proper company code and country, and then $EDO_PROC and $EDO_ORG sit at asterisk because nobody filled them in. The derivation infrastructure is right there. It just was not used.

Connectivity: the objects nobody traces

France operates through approved platforms rather than a single government portal, and SAP connects to those over OAuth 2.0. That brings in an object that does not exist in most role designers' vocabulary.

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 reaches the service provider API
ACTVT = 16, for the token request

Keep OA2C_PROF pinned to the specific profile. Never asterisk it, and never fold this object into a general Basis or catch-all role. The profile name is the only meaningful restriction the object offers, so if you widen it you have effectively removed the control.

There is a question you have to answer before you decide whose role this goes in. Does the token get requested in the dialog user's context, or under the technical user that runs EDOC_BACKGROUND? The answer is often both, and the background user is the one that gets forgotten. Trace it with STAUTHTRACE in a sandbox rather than reasoning about it.

Keep the OAuth client configuration side away from the users who submit. Someone who can both reconfigure the OAuth client and submit documents can point your invoice traffic somewhere else.

S_SERVICE also appears with SRV_TYPE = HT and a list of hashed service names. Those hashes are landscape-specific, generated by SU24 maintenance on your own system, so do not copy them from a template or a blog post. Generate them from your own SU24.

Three things that round out the role

A full DRC France role runs to around forty objects. Most come from the SU24 proposal and need no thought. Three groups do.

The financial drill-down objects (F_BKPF_BUK, F_KNA1_BUK, F_LFA1_BEK and friends) get checked when the user jumps from the cockpit to the source billing or accounting document. Leave them out and the cockpit half-works, which produces a wave of tickets in week one that look like DRC problems and are not.

EDOIN_ORG1 is the India localisation, and it arrives in a France role through the SU24 proposal. Remove it rather than leaving it on asterisk.

And do not forget AIF. Rejected invoices land in the Application Interface Framework, not only in the cockpit. Whoever fixes them needs /AIF/ authorizations scoped to the relevant namespace and interfaces. It is a second console with its own design, usually discovered the first time a batch fails.

Segregation of duties

The French model transmits invoice lifecycle statuses back to the administration. That changes the risk profile of cockpit actions, because suppressing or altering a status is no longer just an internal control issue. It affects reported data.

Four conflicts worth adding to your ruleset before go-live:

Create customer invoice (VF01) combined with cockpit actions that cancel, ignore or manually complete an eDocument. Someone can invoice and then stop the platform seeing it.
Post supplier invoice (MIRO) combined with setting the inbound lifecycle status. Accepting or refusing an invoice on behalf of the company is a business decision, not a technical one.
Maintain DRC customizing in production combined with submit.
Maintain the OAuth client configuration combined with submit.

None of these appear in a standard ruleset, because standard rulesets predate the mandate. You have to write them. If you run your analysis in SAP GRC Access Control, that means custom functions and risks; if you run it in our own tool, MTC Skopos, it means extending the ruleset file. Either way it is manual work that somebody has to own before September.

A workable role model

Three master roles, split by process, because they have different menus, different drill-down targets and different owners:

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

Then derive on company code and country, with $EDO_PROC fixed by the master and $EDO_ORG carrying whatever grouping the business asked for. Split display from action inside each master using EDO_PRSTEP rather than building a separate derivation dimension for it. Sensitivity classification is usually about who can act, not who can see, and answering that question honestly saves you a lot of derived roles.

The e-reporting payment data leg is the one that gets left out of scoping. It is neither AR nor AP, it follows the same September calendar, and it needs an owner.

If you are reading this in August 2026

You are short on time, and an org level conversion is not a two-week change if your roles are already productive. The good news, again, is that on a current release you almost certainly do not need one.

What you do need is to open your existing DRC roles and check what $EDO_PROC and $EDO_ORG are actually set to. If the answer is asterisk, you have a France go-live where every user with the cockpit can see and act on every electronic document in the landscape. That is a finding waiting to happen, and it is a fifteen-minute check.

The short list, in the order it pays off:

Open AGR_1252 for your DRC roles and confirm $EDO_PROC and $EDO_ORG are org levels with real values, not asterisk.
Confirm EDO_BUK and F_SRF_RNTM-COUNTRY are derived per country, so the France role cannot read Italian or Spanish traffic.
Find every role holding S_OA2C_USE and check that OA2C_PROF is pinned, including the background user behind EDOC_BACKGROUND.
Trace the cockpit end to end in a sandbox with STAUTHTRACE, including the drill-down into the billing and accounting documents.
Write the four SoD rules above and run them against the roles you are about to ship.

How MTC helps

We design and review SAP authorization concepts for regulated, multi-country SAP landscapes from Geneva, including the DRC scope behind the French e-invoicing mandate: process and company-code restriction, derived-role models, OAuth and interface exposure, SU24 alignment for Fiori, and the SoD rules that standard content does not carry. On large programs we work alongside leading global audit, risk and technology consulting firms, with the security outcome owned by a senior Swiss-based team.

Frequently Asked Questions

Which authorization objects does SAP DRC use?

The core SAP Document and Reporting Compliance 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, with activity, country and report category). Around these sit the connectivity objects S_OA2C_USE for the OAuth 2.0 client and S_SERVICE for the Fiori/OData services, plus the financial drill-down objects (F_BKPF_BUK, F_KNA1_BUK, F_LFA1_BEK) that get checked when a user jumps from the eDocument Cockpit to the source document. A complete France role typically runs to around forty objects.

Do I need PFCG_ORGFIELD_CREATE to make EDO_PROC and EDO_ORG organizational levels?

On current S/4HANA releases, no. EDO_PROC and EDO_ORG are delivered as organizational levels and appear in PFCG as $EDO_PROC and $EDO_ORG without any conversion. Running PFCG_ORGFIELD_CREATE is a client-independent change that affects every role in the system and requires an impact analysis, a PFCG freeze and mass regeneration, so it is worth checking AGR_1252 or the org-level button on an existing DRC role before planning that work. Being an organizational level does not mean the value is restricted: in most landscapes the derived roles carry a company code and a country while $EDO_PROC and $EDO_ORG sit 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 for issuance. E-reporting (transaction data for B2C and international sales, plus payment data) follows the same calendar.

Which SAP Fiori apps cover Document and Reporting Compliance?

Three apps, and they are not interchangeable: F4306 Manage Electronic Documents (the Fiori equivalent of transaction EDOC_COCKPIT), F5218 Manage Document and Reporting Compliance (the cross-country compliance dashboard) and F1515 Run Statutory Reports (the statutory reporting runtime where e-reporting lives). Behind them sit the OData services EDOC_DCC_SRV, SRF_REPORTING_TASK, CV_ATTACHMENT_SRV, CA_OC_OUTPUT_REQUEST_SRV and CA_FM_FEATURE_TOGGLE_STATUS_SRV, which have to be in the role menu.

What SoD conflicts should be added for French e-invoicing?

Standard rulesets predate the mandate, so four conflicts usually have to be written by hand: creating a customer invoice (VF01) combined with cockpit actions that cancel, ignore or manually complete an eDocument; posting a supplier invoice (MIRO) combined with setting the inbound lifecycle status; maintaining DRC customizing in production combined with submit; and maintaining the OAuth client configuration combined with submit. They matter because the French model transmits invoice lifecycle statuses back to the administration, so suppressing or altering a status affects reported data.