What's new

Invoice Lifecycle Support

Overview

As part of the French e-invoicing mandate TeC now supports submitting, tracking, and receiving invoice lifecycle status updates for French transactions. With this update both the submitter of the invoice and the receiver can participate in updating the invoice status.

Availability: Domestic French invoices, for members onboarded to French CTC services. Suppliers and buyers that are not enrolled for French CTC are blocked at submission.

Submission prerequisites

• Member role confirmed on the invoice (buyer/supplier)

• Invoice has final clearance/retrieval status​

• Member has active onboarding and relevant service enabled

• Submitted status type matches member role​

Status types

French lifecycle statuses are split into platform statuses (system-generated) and business statuses (submitted by the parties).

Platform statuses:

• Submitted, Issued, Received, Made Available

• Returned by the platform/clearance provider as the invoice progresses through delivery - no party submits these manually.

• Each is recorded with date/time and a log entry, visible in the supplier/buyer log.

• Made Available means the invoice has been made available to the recipient on their external platform.

Business statuses:

• Buyer can submit:Acknowledged (In Hand), Approved, Partially Approved, Invalidated, Queried, Rejected, Paid.

• Supplier can submit:Payment Collected, Completed.

• These are submitted only once the invoice is delivered/Made Available, to reflect the real-world business handling of the invoice (acceptance, payment, refusal).

Role-based guards

• Buyer cannot submit Payment Collected.

• Supplier cannot submit Approved or Paid.

• Rejected / Refused is terminal - no further statuses can be submitted afterwards.

UI changes

• Both buyer and supplier can submit statuses from the portal (not API only); the status drop-down is limited by role, so each party sees only the statuses allowed for them.

• Supplier and self-billing (buyer) invoices appear in the Sent list; retrieved invoices appear in the Received list.

• Platform and business statuses are shown sequentially in the workflow status pop-up, each with the response received + payload records.

API changes

Lifecycle status updates must be explicitly marked with statusDocument: true to be processed as trackable lifecycle documents - without this flag, the status is handled as a standard invoice update

• Submit a lifecycle status update

  • PATCH /members/{memberId}/invoices/{invoiceId} - now accepts statusDocument (boolean) and statusFields (name/value pairs). If statusDocument is false/omitted, existing behavior is preserved. Access extended to suppliers.

• Track a submitted status

  • GET /members/{memberId}/invoices/{invoiceId}/status-updates

• View invoice submission history

  • GET /members/{memberId}/invoices/submissions/{invoiceSid}

• Test-flow equivalents added: PATCH .../test-invoices/{invoiceId} and GET .../test-invoices/{invoiceId}/status-updates.

• Failed prerequisites (member settings, role/status mismatch) now return 4xx Bad Request.

E-reporting

Overview

As part of the French e-invoicing mandate, TeC now supports submitting e-reporting data to the French government tax authority portal. Unlike the invoice lifecycle, e-reporting is not connected to the invoice flow - TeC acts purely as a gateway: customers upload their e-report (XML) and TeC forwards it, via a shared standalone E-Reporting Service to the French portal.

Enablement (member onboarding)

• Enabled per member via a E-reporting checkbox in the clearance onboarding page in UI, plus at least one notification email (mandatory by government regulation; max 10 emails) for submission status notifications.

• Once e-reporting is activated for the first time, email addresses are locked - the member cannot edit them. Changes require contacting support.

• Disabling/re-enabling uses the same toggle; emails are entered only once (on first enablement) and do not need to be re-entered on reactivation.

Submission flow

E-reporting works in two main communication steps:

1. Create submission + get upload URL

• The customer calls TeC to create a new submission, passing fileName, fileSizeBytes, and md5Checksum.

• TeC communicates with the E-Reporting Service, which returns a signed upload URL (external storage) and its expiration time.

• TeC records the submission with status Awaiting Upload.

1. Upload the file

• The customer uploads the e-report XML directly to the returned upload URL (TeC does not store the bytes).

• The E-Reporting Service detects the upload, runs internal validation, and forwards the data to French portal.

• TeC runs a scheduled job that polls the E-Reporting Service for status updates on active submissions and updates its database; the latest status is returned on the customer's next status call.

Submission statuses

• Awaiting Upload → initial state after submission is created.

• Abandoned → upload URL expired (or explicitly abandoned by the customer) before the file was uploaded.

• Transmitted → file uploaded and passed through for submission.

• Accepted → accepted by the portal.

• Rejected → rejected by the portal.

• Validation Failed → failed validation (at Sovos or the E-Reporting Service).

Note: For rejection/validation failures, the response includes an explanatory message. For system errors, the message directs the customer to contact technical support.

API changes (public)

New e-reporting endpoints under /members/{memberId}/ereporting/... (and /test-ereporting/... for pre-production). Require e-reporting service enabled via UI first.

Create submission - POST .../submissions

Upload - file is POST-ed directly to the returned upload URL (e-report XML as payload).

Get status - GET .../submissions/{id}

List submissions - GET .../submissions

Refresh upload URL - POST .../submissions/{id}/upload-url

Abandon - POST .../submissions/{id}/abandon

• Moves the submission to Abandoned and frees the idempotency key; valid only while in Awaiting Upload.

UI changes

• Member settings show E-Reporting active/not active, the notification-email table (locked after first activation), and the Configure production action.

• Customer interfaces display reporting status, validation results, portal responses, and error notifications.

Before French companies can use services such as clearance and retrieval, you must set them up according to the French identifier structure (SIREN, SIRET, routing codes, and suffixes). The clearance onboarding page now supports requirements for the French e-invoicing mandate.

E-reporting support will be available in a future release.

Onboarding page and prerequisites

• The onboarding page for French members displays a prerequisites checklist with status indicators (✓ or ✗). Complete all prerequisites before you register a customer:

  • Add SIREN and VAT numbers to party identifiers.

  • Set the head office SIRET on the legal address.

  • The legal address identifier must be of type SIRET. No other identifier type is accepted.

  • The legal address must include a street address and city. The PA provider requires this information.

  • Enable at least one sender or recipient endpoint for an address.

  • Clearance workflow enabled—When you enable the clearance workflow, invoices are routed through the French portal for clearance and e-reporting.

  • Verification contact provided (required for production—not applicable for preproduction).

Identity verification (KYC)

• French members must pass identity verification (KYC) before they use production services.

• The provider has not yet fully implemented this feature. In this release, KYC and production service fields are disabled. Professional Services (PS) assists with KYC.

Establishments and endpoints

• The establishments table displays the member's structure, including the head office and child establishments. You can expand the table to display suffixes, routing codes, and registered endpoints.

• Endpoints have a direction (inbound = receiving/retrieval, outbound = sending/clearance), an address type (for example, SIREN/SIRET/routing code), and an environment (production/preproduction).

• Validation rule: You can add a routing code only if its SIRET already exists. Otherwise, the system blocks it with an error.

Endpoint configuration

You can manage endpoint updates from three locations: the Onboarding page (using the Establishments table), the Address List, and the Edit Address page.

You can manage multiple endpoints simultaneously. Use the checkboxes to select or clear items in the Publish section, and then click Request endpoint changes.

• Before you publish endpoints, ensure that the corresponding services are enabled: clearance for outbound endpoints and retrieval for inbound endpoints.

• You make changes using draft changes, which are marked with an asterisk. Draft changes persist across page refreshes and are applied only when you click Request endpoint changes.

• The Request endpoint changes button handles different actions: publish, unpublish, and update validity dates.

• You can delete endpoints only after you unpublish them.

Validity dates

When the endpoint validity period expires, you can no longer use the endpoint to route or sync invoices. To extend validity, go to the Address edit page or Establishment overview page, update the Valid To date, and then click Request endpoint changes.

• Valid From is automatically set to D+1 (the day after creation)—the Annuaire does not accept today's date as the valid from date. You can edit validity both before and after you publish.

• While a validity date change is in progress, the record shows both the current (confirmed) valid-to date as registered in the network and the requested date. This helps you understand that the change is still pending.

Request handling

• The Request log provides full visibility into all triggered requests, including company registration, service activation, and endpoint creation or updates. This makes it easy to track the status of every onboarding and configuration action.

• Retry: You can retry failed requests. Retry rechecks the latest member configuration so that user-corrected mistakes are picked up before resending.

• If any request within the onboarding process is In Progress, you are alerted to wait before making further changes. However, if you proceed and add an address, the system automatically creates a new request after the current one completes.