Submit an electronic invoice, e-reporting, or lifecycle status to the Approved Platform.

Scope: Compatible Solution (CS) mode, no payload validation. See README "Scope" section.

This is the primary action for sending B2B invoices (Factur-X, UBL, CII), B2BInt/B2C e-reportings, or CDAR lifecycle status messages.

HUMAN-IN-THE-LOOP: This tool requires explicit user confirmation. Call without confirmation_token first; show the returned summary to the user; then call again with the provided token to execute the submission.

BEHAVIOR:

• Submission is asynchronous: the AP returns a flowId and an initial status (typically 'Deposited'), not the final delivery status. Poll get_flow(flow_id) or search_flows to track processing.

• Returns an error dict (with 'error' key) if the base64 encoding is invalid.

• The AP may reject the flow synchronously (e.g. malformed XML, unknown recipient, quota exceeded); in that case the response contains an error code and message.

• If processing_rule is B2B, the recipient must be registered in the PPF directory with an active directory line; verify with get_directory_line before submitting.

RESPONSE on success: includes flowId (AP-assigned identifier), trackingId (echoed back), status (initial processing status), and submittedAt timestamp.

USAGE GUIDELINES:

• Always call get_directory_line (or search_directory_line) first to confirm the recipient is reachable and to identify their Approved Platform before submitting a B2B invoice.

• Set a meaningful tracking_id (invoice number or UUID) to simplify later retrieval via search_flows.

• After submission, use get_flow(flow_id, doc_type='Metadata') to monitor the flow status.

• For lifecycle statuses on received invoices (Refused, Approved, etc.), prefer submit_lifecycle_status which provides structured status fields and handles mandatory PPF transmissions.

• Call healthcheck_flow before a batch submission to confirm the AP is available.

Search flows (invoices, statuses, e-reportings) in the Approved Platform by criteria: flow type, status, processingRule, period, trackingId. Pagination via updatedAfter: use the 'nextUpdatedAfter' field from the response as the updated_after parameter value to get the next page.

Retrieve a flow by its identifier. docType allows choosing between JSON metadata (Metadata), the original document (Original), the converted document (Converted), or the readable representation (ReadableView). By default, returns the JSON metadata (status, dates, identifiers).

Emit a processing status on a received invoice: Refused, Approved, PartiallyApproved, Disputed, Suspended, Cashed, PaymentTransmitted, Cancelled. Refused and Cashed are mandatory transmissions to PPF. Reason is mandatory for Refused, Disputed, PartiallyApproved, and Suspended.

Builds a real CDAR (CrossDomainAcknowledgementAndResponse, XP Z12-014 v1.4) document — see mcp_facture_electronique_fr.clients.flow_client for the MDT-* field mapping this depends on.

HUMAN-IN-THE-LOOP: Requires user confirmation. Call without confirmation_token first, show the summary to the user, then call again with the token.

Check the availability of the Approved Platform's Flow Service. Returns the operational status of the service (ok/degraded/unavailable). Use before an invoice submission session to ensure the AP is reachable.

Validate a DGFiP e-reporting (Flux 10) FRR XML payload.

Scope: XSD schema validation only, no business-rule checks. See README "Scope" section.

Checks the XML against the DGFiP Spécifications Externes v3.2 ereporting.xsd. Returns validation result with errors if any. Use this before submitting to catch structural problems early.

Validation levels (in order of preference):

• xsd — full schema validation

• wellformedness — XML failed to parse (malformed or unsafe input)

• none — XSD files not found on disk

Submit a DGFiP Flux 10.1 / 10.3 transaction e-reporting flow.

Scope: Compatible Solution (CS) mode, no payload validation. See README "Scope" section.

Builds a FRR XML payload conforming to DGFiP Spécifications Externes v3.2 (transaction.xsd / ereporting.xsd) and submits it to the Approved Platform via POST /v1/flows with flowSyntax="FRR".

Use for:

• International B2B outbound sales (processing_rule=B2BInt, flow_type=IndividualCustomerTransactionReport)

• International B2B inbound purchases (processing_rule=B2BInt, flow_type=UnitarySupplierTransactionReport)

• B2C individual transactions (processing_rule=B2C, flow_type=IndividualCustomerTransactionReport)

• Aggregated B2C reports (processing_rule=B2C, flow_type=AggregatedCustomerTransactionReport)

Submit a DGFiP Flux 10.2 / 10.4 payment e-reporting flow.

Scope: Compatible Solution (CS) mode, no payload validation. See README "Scope" section.

Builds a FRR XML payload conforming to DGFiP Spécifications Externes v3.2 (payment.xsd / ereporting.xsd) and submits it to the Approved Platform via POST /v1/flows with flowSyntax="FRR".

Use for:

• International B2B payment reporting (processing_rule=B2BInt, flow_type=UnitaryCustomerPaymentReport)

• B2C individual payment reporting (processing_rule=B2C, flow_type=UnitaryCustomerPaymentReport)

• Aggregated B2C payment reporting (processing_rule=B2C, flow_type=AggregatedCustomerPaymentReport)

Validate a Factur-X CII XML document against its profile's Schematron ruleset.

Scope: Schematron (SVRL) business-rule validation only, no XSD structural check. Returns is_valid, errors, and warnings (rule_id, location, text). Use this before embedding the XML into a PDF/A-3 or submitting via submit_flow.

Requires the optional saxonche extra (FR-XSLT2-1, resolved in mcp-einvoicing-core 1.14.0): the bundled Factur-X 1.08 Schematron stylesheets require XSLT 2.0, which lxml/libxslt (XSLT 1.0 only) cannot compile. Install with pip install mcp-facture-electronique-fr[xslt2]. If it is missing, this tool returns level="unavailable" with is_valid=None instead of raising.

Search legal units (SIRENs) in the PPF Annuaire (POST /siren/recherche).

A company must appear here before its establishments (SIRETs) or directory lines (ligne-annuaire) can be resolved. Prefer get_company_by_siren when the exact SIREN is already known.

Look up a legal unit by SIREN (GET /siren/code-insee:{siren}).

Look up a legal unit by directory instance ID (GET /siren/id-instance:{id-instance}).

Search establishments (SIRETs) in the PPF Annuaire (POST /siret/recherche).

Look up an establishment by SIRET (GET /siret/code-insee:{siret}).

Look up an establishment by directory instance ID (GET /siret/id-instance:{id-instance}).

Search routing codes (POST /code-routage/recherche).

Look up a routing code by SIRET and code (GET /code-routage/siret:{siret}/code:{identifiant-routage}).

Look up a routing code by directory instance ID (GET /code-routage/id-instance:{id-instance}).

Create a routing code (POST /code-routage).

HUMAN-IN-THE-LOOP: Requires user confirmation. Call without confirmation_token first, show the summary to the user, then call again with the token.

Partially update a routing code (PATCH /code-routage/id-instance:{id-instance}). Only provided fields are modified.

Fully replace a routing code (PUT /code-routage/id-instance:{id-instance}). Unlike update_routing_code, all fields are required and replace the existing object entirely.

HUMAN-IN-THE-LOOP: Requires user confirmation. Call without confirmation_token first, show the summary to the user, then call again with the token.

Search directory lines (electronic invoice receiving addresses) (POST /ligne-annuaire/recherche).

Call before sending an invoice to verify the recipient has a registered line and to identify their Approved Platform.

Look up a directory line by addressing code (GET /ligne-annuaire/code:{identifiant-adressage}).

Look up a directory line by directory instance ID (GET /ligne-annuaire/id-instance:{id-instance}).

Create a directory line (electronic invoice receiving address) (POST /ligne-annuaire).

HUMAN-IN-THE-LOOP: Requires user confirmation. Call without confirmation_token first, show the summary to the user, then call again with the token.

Partially update a directory line (PATCH /ligne-annuaire/id-instance:{id-instance}). Only provided fields are modified.

Fully replace a directory line (PUT /ligne-annuaire/id-instance:{id-instance}).

HUMAN-IN-THE-LOOP: Requires user confirmation. Call without confirmation_token first, show the summary to the user, then call again with the token.

Delete a directory line (DELETE /ligne-annuaire/id-instance:{id-instance}).

HUMAN-IN-THE-LOOP: Requires user confirmation. Call without confirmation_token first, show the summary to the user, then call again with the token.

Check the availability of the PPF Annuaire service (GET /healthcheck). Use before a directory-management session to ensure the service is reachable.

List all webhook subscription IDs owned by the current OAuth2 token holder.

Returns a list of webhook UUIDs. Use get_webhook with each ID to retrieve the full subscription details (callback URL, filters, authentication).

Retrieve the full details of a webhook subscription: callback URL, authentication mode, signature configuration, and metadata filters (flow type, direction, processing rule, ack status).

Subscribe to webhook notifications from the Approved Platform.

The AP will POST event payloads to the callback URL whenever a flow matching the specified filters (flow type, direction, processing rule, ack status) is created or updated.

HUMAN-IN-THE-LOOP: Requires user confirmation. Call without confirmation_token first, show the summary to the user, then call again with the token.

Update a webhook subscription's technical parameters (authentication, signature, custom headers). Metadata filters (flow type, direction) cannot be changed; delete and recreate the webhook instead.

Only provided fields are modified (PATCH semantics).

Delete (unsubscribe from) a webhook. After deletion, the AP will stop sending notifications to the callback URL.

HUMAN-IN-THE-LOOP: Requires user confirmation. Call without confirmation_token first, show the summary to the user, then call again with the token.