Skip to main content

E-Reporting

The E-Reporting editor configures how NomaUBL produces and submits the periodic e-Reporting bundles required by the French e-invoicing reform. Each company files a regulatory report covering its B2BINT, B2C and out-of-scope flows on a fixed cadence (monthly by default); this page controls the sender / issuer identity emitted in the bundle, the cadence and flux selection, and the PA transport used to upload the bundle once generated.

The page applies regardless of source system — JD Edwards, SAP, NetSuite or a custom ERP — once the source is mapped to UBL.

Refreshed in 2026.05.8

E-Reporting is now fully decoupled from E-Invoicing. It picks its own api-connector, its own endpoint.report-import and its own paMode, so reporting can target a different platform — or use different credentials on the same platform — than invoice import. A new SFTP transport lets the bundle be uploaded as a file drop instead of a REST POST. The legacy sendToPA Y/N flag was replaced by paMode (API / FTP / empty) for consistency with E-Invoicing. The configuration check now flags paMode=API without a connector and paMode=FTP without paFtpHost as errors.

The editor has four tabs:

  1. Identity — Sender (PA) and Issuer (Declarant) identification fields emitted in the bundle.
  2. Reporting — Business Process (B2BINT) plus Schedule and Flux selection.
  3. PA Connection — picks the api-connector that holds the PA's HTTP transport, plus the per-task endpoint name override and connection-level parameters.
  4. FTP/SFTP — Send Mode toggle and the SFTP server credentials used when the toggle is set to FTP.

Opening the editor

  • Settingse-reporting template (the system-level resource).
  • The default scope is the platform-wide e-reporting template. Per-company overrides live on e-reporting-{kco} templates and follow the same shape; the runtime resolver looks at the per-company template first and falls back to the platform-wide one.

At a glance

IdentityReportingPA ConnectionFTP/SFTPSender (PA)MATRICULEPA01ROLE CODEWKIssuer (Declarant)SIREN123456789SCHEME0002 ▾ROLESE ▾Reporting tab — previewFREQUENCYMONTHLY ▾FLUX10.1,10.3PA Connection tab — previewCONNECTORpa-default ▾independent of e-invoicingREPORT IMPORT ENDPOINTreport-importFTP/SFTP tab — previewSEND MODEAPI ▾empty = generate without submissionSFTP SERVERused when Send Mode = FTPHost | ftp.plateformeagree.frPort | 22Outbound | /out/reports/Inbound | /in/reports/Sender + Issuer identityemitted in every report bundleFrequency + Fluxdrives the scheduler periodOwn api-connectorindependent from e-invoicingpaMode = API/FTP/emptyreplaces sendToPA Y/N

Tab 1 — Identity

The Identity tab carries the actors emitted on every report bundle. Both blocks are rendered as XML elements inside the AFNOR XP Z12-014 envelope (<Sender> and <Issuer>).

Sender (PA)

FieldDefaultDescription
MatriculePA matricule (4 chars), emitted as <Sender><Id schemeId="0238">.
NameOptional. Emitted as <Sender><Name>.
Role CodeWKDefault WK (PA). Emitted as <Sender><RoleCode>.

Issuer (Declarant)

FieldDefaultDescription
Identifier (SIREN)Declarant identifier emitted as <Issuer><Id schemeId="0002">.
NameOptional. Emitted as <Issuer><Name>.
Scheme ID0002ISO 6523 ICD scheme. Default 0002 (SIREN France).
Role CodeSESE for sales reporting (default), BY when reporting purchases.
Companies (kco) override(empty)Comma-separated list of companies to process. Leave blank to auto-detect from invoices and per-company override templates.

Tab 2 — Reporting

Business Process (B2BINT only)

These fields are emitted on per-invoice <BusinessProcess> elements, only for B2BINT invoices.

FieldDescription
Business Process IDOptional. TT-28 cadre de facturation (e.g. B1, P1).
Business Process Type IDOptional. TT-29 specification identifier.
Flow NameOptional. TT-2 emitted as <ReportDocument><Name>.

Schedule & Flux

FieldDefaultDescription
FrequencyMONTHLYDrives the period auto-computed by the scheduler and the Generate dialog default.
Flux10.1,10.3Comma-separated flux codes. Default covers Flux 10.1 (B2BINT detail) and Flux 10.3 (B2C / OUTOFSCOPE aggregated).
Default Type CodeINDefault report type code.

Tab 3 — PA Connection

API connector

The PA's HTTP transport — authentication flow, base URL, endpoints — lives in a reusable api-connector. E-Reporting picks its own connector rather than sharing the one set on E-Invoicing, so reporting can target a different platform — or use different credentials on the same platform — than invoice import.

FieldDescription
ConnectorDropdown listing every api-connector template. Use a different connector than e-invoicing if the reporting flow goes to a separate platform or uses different credentials. Edit the connector itself under API Connectors.

Per-task endpoint override

FieldDefaultDescription
Report importreport-importEndpoint name on the picked connector for report submission. Leave blank to use the default.

Connection

FieldDefaultDescription
Timeout (ms)30000HTTP request timeout in milliseconds. Long-running submissions are aborted past this.
SSL VerifytrueWhether to validate the PA's TLS certificate. Set to false only in non-production environments using self-signed certificates.

Tab 4 — FTP/SFTP

Send Mode

FieldValuesDescription
Send Mode (paMode)API (default) / FTP / (empty)Transport used to submit generated reports to the PA. API routes the bundle through the api-connector picked on the previous tab; FTP spools the report XML to a temp file and uploads it via SFTP using the server below; (empty) lets NomaUBL generate reports without submitting them — useful while validating identity and flux selection before involving the PA.

The paMode field replaces the legacy sendToPA Y/N flag in 2026.05.8. Same semantics, single field, consistent with E-Invoicing.

SFTP Server

The whole card is dimmed when Send ModeFTP — these fields only apply to the SFTP transport.

FieldDescription
HostSFTP host (e.g. ftp.plateformeagree.fr).
PortSFTP port. Default 22.
UserSFTP user.
PasswordSFTP password.
Outbound DirRemote directory where NomaUBL drops report bundles for the PA (e.g. /out/reports/).
Inbound DirRemote directory where the PA writes acknowledgements (e.g. /in/reports/).

Configuration check

The configuration check on the Tech Dashboard validates the template against the new shape:

  • paMode=API without a connector is reported as an error (the API transport has nothing to call).
  • paMode=FTP without paFtpHost is reported as an error (the SFTP transport has no server).
  • paMode= (empty) with a connector is fine — reports generate locally and are not submitted.
  • issuerSiren, frequency and flux are validated whenever paMode is non-empty (i.e. the bundle will actually be submitted).

The legacy sendToPA=Y / issuerSiren check is gone — replaced by the per-paMode rules above.


Tips & best practices

  • Pick a separate api-connector when the reporting platform differs. A multi-platform install often has e-invoicing on one PA and e-reporting on another — that's why each system template carries its own connector reference. Set both to the same connector name when they share a platform.
  • Start with paMode= (empty) when first wiring the company up. NomaUBL generates the report locally so identity and flux selection can be validated against a sample without touching the PA. Flip to API once the bundle reads correctly.
  • Use SFTP only when the PA mandates file drop. REST submission is simpler to debug and works with the api-connector test panel; SFTP is appropriate for high-volume submissions or when the PA does not expose a REST report-import endpoint.
  • Per-company overrides go on e-reporting-{kco}. Copy the platform-wide e-reporting template under the new name from Settings and edit only the fields that differ — typically issuerSiren, the connector reference, or the SFTP credentials when company 00070 reports through a different platform.
  • Frequency drives the auto-computed period. Setting it to MONTHLY makes the scheduler emit one bundle per month covering the previous month; QUARTERLY extends the window. The Generate dialog still lets the user override the period at run time.
  • Companies (kco) override is rarely needed. NomaUBL auto-detects companies from the invoices it processes and from the existence of e-reporting-{kco} templates. Set the field manually only when reporting must be limited to a subset (e.g. one division during a phased rollout).