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

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

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 and Disputed.

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.

Search for companies (legal units / SIRENs) in the PPF directory by criteria.

Returns VAT-registered French legal units recorded in the PPF directory. A company must appear here before its establishments (SIRETs) or directory lines can be used.

BEHAVIOR:

• Returns a paginated list of matching companies; empty list if none match.

• At least one search criterion must be provided; omitting all returns an error.

• Name search is a partial, case-insensitive match against the legal name and trade name.

• Pagination: if the response contains 'nextUpdatedAfter', pass it as updated_after to get the next page.

RESPONSE: each item includes siren, name, status (Active/Inactive/Pending), approvedPlatformId, and timestamps (createdAt, updatedAt).

USAGE GUIDELINES:

• Prefer get_company_by_siren when you already know the exact SIREN (faster, direct lookup).

• Use search_company with name to resolve a company name to its SIREN before further lookups.

• Always check status == Active before attempting to send invoices to or look up establishments for a company.

• A company not present in the directory is not yet registered for e-invoicing; invoices cannot be routed to it.

• After finding the SIREN, call search_establishment or get_directory_line to find the recipient's address.

Look up a company in the PPF directory by its SIREN number. Returns the full legal unit information: company name, administrative status, associated Approved Platform, and registration dates.

Search for establishments (SIRETs) in the PPF directory by criteria.

An establishment is a physical place of business activity identified by its 14-digit SIRET. Each company (SIREN) can have multiple establishments.

BEHAVIOR:

• Returns a paginated list of matching establishments; empty list if none match.

• At least one search criterion should be provided; omitting all returns an error.

• Pagination: if the response includes 'nextUpdatedAfter', pass it as updated_after to get the next page.

RESPONSE: each item includes siret, siren, name, administrativeStatus (Active/Inactive), approvedPlatformId, and timestamps (createdAt, updatedAt).

USAGE GUIDELINES:

• Prefer get_establishment_by_siret when you already know the exact SIRET (faster, direct lookup).

• Use search_establishment with siren to enumerate all establishments of a company.

• Always verify administrativeStatus == Active before sending an invoice to that establishment.

• Call this before create_directory_line to confirm the target SIRET is registered in the PPF directory.

Look up an establishment in the PPF directory by its SIRET number. Essential for verifying the receiving address before sending an invoice. Returns the establishment details, its status, and its Approved Platform.

Search routing codes registered in the PPF directory for a recipient.

Routing codes subdivide a SIRET receiving address to department or service level, allowing a company to route invoices to different internal units (e.g. purchasing, accounting).

BEHAVIOR:

• Returns a paginated list of matching routing codes; empty list if none defined for the criteria.

• At least one of siret, siren, or routing_code should be provided.

• A SIRET may have zero or more routing codes; zero means invoices go to the SIRET-level address.

RESPONSE: each item includes instanceId, siret, siren, routingCode, label (optional), and timestamps. The instanceId is required to update or delete a routing code.

USAGE GUIDELINES:

• Call before create_directory_line with a routing_code to confirm the code exists on the target SIRET.

• Call to enumerate available routing codes when helping a sender choose the correct recipient address.

• If no routing codes exist for a SIRET, the invoice must be addressed at SIRET level without a routing code.

• Use create_routing_code to create a new code; use update_routing_code with instanceId to rename it.

Create a new routing code for a SIRET in the PPF directory.

Routing codes let a recipient company route incoming invoices to specific departments or services. Once created, the code can be referenced in a directory line (create_directory_line) and communicated to senders to use in invoice addressing.

BEHAVIOR:

• Returns the created routing code object including its instanceId.

• Fails if the SIRET is not registered or not Active in the PPF directory.

• Fails if a routing code with the same value already exists for this SIRET (duplicate check).

• The routing_code value is case-sensitive and must be unique per SIRET.

RESPONSE: includes instanceId (required for update/delete), siret, siren, routingCode, label, createdAt.

USAGE GUIDELINES:

• Call get_establishment_by_siret first to verify the SIRET is Active before creating a routing code.

• After creating, call create_directory_line with routing_code set to register the receiving address.

• If a routing code already exists (duplicate error), use search_routing_code to retrieve its instanceId, then update it with update_routing_code if needed.

• Routing codes are optional; omit them if the company routes all invoices to a single SIRET address.

Partially update an existing routing code in the PPF directory (PATCH semantics).

Only the fields explicitly provided are modified; omitted fields keep their current values. Use to rename a routing code value or update its label without recreating it.

BEHAVIOR:

• Returns the updated routing code object on success.

• Fails with 404 if the instanceId does not exist.

• Fails if the new routing_code value is already used by another routing code on the same SIRET (duplicate).

• Updating routing_code renames it in-place; existing directory lines referencing it are updated automatically.

• Providing neither routing_code nor label is a no-op (returns the unchanged object).

RESPONSE: the full updated routing code object — instanceId, siret, siren, routingCode, label, updatedAt.

USAGE GUIDELINES:

• Retrieve the instanceId first via search_routing_code if you only know the routing code value.

• Prefer updating the label for cosmetic changes; only change routing_code if the identifier itself must change (e.g. department renamed), since senders may have cached the old value.

• To delete and replace a routing code entirely, use delete on the old instanceId and create_routing_code for the new one.

Search directory lines (electronic invoice receiving addresses) for a taxable entity.

A directory line maps an addressing identifier (SIREN, SIREN/SIRET, or SIREN/SIRET/routing-code) to an Approved Platform and an optional technical address. It is the authoritative record of where the recipient wants to receive invoices.

BEHAVIOR:

• Returns a paginated list of matching directory lines; empty list if the entity has no registered lines.

• At least one search criterion should be provided; omitting all may return an error or a very large result set.

• Pagination: if the response contains 'nextUpdatedAfter', pass it as updated_after to retrieve the next page.

• A recipient can have several lines (e.g. one at SIREN level plus specific ones per SIRET or routing code); the most specific line (SIREN/SIRET/routing-code) takes precedence over less specific ones.

RESPONSE: each item includes instanceId, addressingIdentifier (SIREN[/SIRET[/routingCode]]), approvedPlatformId, technicalAddress (optional), and timestamps (createdAt, updatedAt). The instanceId is required for update_directory_line and delete_directory_line.

USAGE GUIDELINES:

• Prefer get_directory_line with the full addressingIdentifier when you know the exact address (faster, avoids pagination).

• Use search_directory_line with siren to audit all receiving addresses of a company.

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

• If no lines are returned, the recipient is not yet registered in the PPF directory and cannot receive electronic invoices; they must register via create_directory_line or through their AP.

• The instanceId from results is needed to call update_directory_line or delete_directory_line.

Look up a directory line by its addressing identifier. Use before any invoice submission to verify recipient reachability and obtain their receiving Approved Platform. Returns 404 if the recipient is not yet registered in the PPF directory.

Create a directory line (electronic invoice receiving address) for a taxable entity. Required to register in the PPF directory and allow other companies to send you electronic invoices. A line can be at SIREN level (entire company), SIREN/SIRET (one establishment), or SIREN/SIRET/routing-code (a specific department).

Partially update an existing directory line. Only the provided fields are modified (PATCH semantics). Typically used to update the technical address after a configuration change on the Approved Platform side.

Delete a directory line. Use when changing Approved Platform or closing an establishment. After deletion, create a new line via create_directory_line if needed. WARNING: irreversible action — verify the instance_id before calling this tool.