>Connect the invoice to payment>and cash management

No. This page does not present Tractial as an Accredited Platform.

Tractial acts as fintech infrastructure and Payment Institution. Its role is to enable the embedding of financial services (payment accounts, IBANs, collections, transfers, reconciliation and reporting) in invoicing platform journeys.

The Accredited Platform keeps the responsibilities that are its own in the French e-invoicing scheme.

An Accredited Platform can build an experience that combines invoicing and financial services by relying on the appropriate providers and frameworks.

Tractial can assess embedding payment accounts, IBANs, collections, transfers and payment data directly in the platform journey.

The precise model depends on each party’s role, the users involved, the flows and the required regulatory validations.

The IBAN creates a more direct link between the invoice and the settlement.

Tied to a payment account embedded in the journey, it can receive a settlement, identify the financial movement and then match it to the corresponding invoice.

For the platform, the aim is to reduce the break between invoice tracking and collection tracking.

Payment accounts and IBANs can be embedded according to the chosen model and the validated perimeter.

Whether an IBAN can be associated with a user or a business depends in particular on the nature of the service, the KYC/KYB journey, the flows involved, each party’s responsibilities and the applicable regulatory framework.

The model is therefore defined project by project with Tractial.

A supplier payment journey can be assessed in order to bring invoice validation closer to settlement execution.

Depending on the chosen model, the platform can pass the information the journey needs: beneficiary, amount, reference and due date.

Payment remains subject to the applicable authorisation, control and validation mechanisms.

Mechanisms to prepare or schedule payment can be assessed when the journey, user rights and applicable framework allow it.

The aim is, for example, to let the user validate today an invoice whose payment should be executed on a given due date.

Automation must not, however, remove the required controls or authorisations.

Reconciliation can be largely automated when the available data identifies the invoice and the corresponding movement reliably enough.

Amount, payment references, payer identity, IBAN or business data can all contribute to the match.

Ambiguous or incomplete cases must remain identifiable so they can be handled in the software workflow.

Yes, depending on the integration perimeter.

APIs, webhooks or other exchange mechanisms can return available financial events to the software: payment received, operation in progress, transfer executed, rejection, anomaly or another relevant status.

The user can then follow the invoice and its payment from the same interface.

These are two different notions.

Regulatory e-reporting belongs to the French e-invoicing scheme and to the obligations and circuits provided for Accredited Platforms and the businesses concerned.

Tractial financial reporting covers operational information tied to payment services: movements, amounts, balances, beneficiaries, statuses or reconciliations. Where relevant, this information can feed the platform’s system, but it does not replace its regulatory obligations.

No.

It can also concern compatible solutions, invoicing vendors, ERPs, B2B SaaS, accounting software or treasury solutions that want to connect their business data to financial services.

Each actor’s role and how it articulates with an Accredited Platform must be defined according to its model.

Integration is designed around Payment.net and the interfaces made available according to the project.

The partner’s teams can connect the required features (accounts, IBANs, payments, statuses, reconciliation or reporting) to their own screens and workflows.

The technical perimeter is defined during scoping, then tested before go-live.