B2B SaaS and business software
Connect the business actions of your company clients to their payment operations.
Embed payment accounts, IBANs, collections, transfers and reconciliation data in the software they use every day.
- Your software
- Payment account and IBAN
- Collections and transfers
- Statuses and reconciliation
Data returned in your product
In brief
Connect the work inside the software to the company’s payments
Embedded finance means integrating financial services into a software journey. For a B2B vendor, that makes it possible to tie an invoice, an intervention, an order or a file to a payment account, a settlement and its status.
Tractial provides the payment services that fall within its Payment Institution perimeter. The vendor keeps the design of its product and connects the chosen functions, under a technical, operational and contractual model defined together.
CollectPayReconcileSteer
User experience
A business journey that continues through to payment
Your client already prepares invoices and tracks activity in your tool. A financial integration can match this information to movements that have actually been received or executed, then surface the operations that still need action.
Today, scattered steps
The invoice is tracked in the software, payment is prepared in another space, and information comes back through export or re-keying. Gaps keep teams busy.
An embedded financial journey
The software can tie the business document, the relevant account, the user’s authorisation and the available statuses together. Unmatched cases remain identified and actionable.
Integration does not remove the required controls or authorisations.
From the business object to the movement
Track a settlement without losing its business reference
A useful collection is a collection your client can explain. The link between payer, beneficiary company and business reference gives context to the financial movement.
Business object
An invoice or a file describes the amount and the expected counterparty.
Client settlement
The payer uses the payment method that is offered and authorised.
Company account
Funds are received in the account structure validated for the project.
Movement identified
Amount, reference and available identifiers are passed to the software.
Reconciliation
The software matches the movement to the business object, or flags a discrepancy.
Tracking in the tool
The client finds the information needed to handle the file.
Four journeys
Financial functions tied to your business screens
Start with a frequent action that is useful to your users. Each journey can be embedded progressively, with its data, rights and exceptions.
Tie the settlement to a customer invoice
Present the useful payment information, then attach the received movement to the relevant invoice. Your client can track what has been paid and what is still expected from inside the software.
Teaching example. Fictional data.
- Invoice
- FAC-2026-084
- Beneficiary company
- Atelier Exemple SAS
- Amount expected
- €2,480.00
- Amount received
- €2,480.00
- Situation
- Matched
Prepare a supplier payment
From an approved expense, prepare the operation details: beneficiary, amount, reference and due date. Payment follows the applicable authorisation and control mechanisms.
Teaching example. Fictional data.
- Supplier invoice
- FOU-2026-031
- Beneficiary
- Fournisseur Exemple SARL
- Amount
- €1,240.00
- Due date
- 30 October 2026
- Situation
- To authorise
Handle partial payments and discrepancies
Use the available references and amounts to propose a match. When a payment is incomplete, grouped or unidentified, the software keeps an explicit situation to review.
Teaching example. Fictional data.
- Invoice
- FAC-2026-085
- Amount expected
- €2,480.00
- Amount received
- €1,480.00
- Amount still expected
- €1,000.00
- Situation
- Partial payment
Separate the available balance from expected flows
Present executed movements and due dates from the software in one operational reading. A forecast calculated in the SaaS remains distinct from the payment-account balance.
Teaching example. Fictional data.
- Available balance
- €18,400.00
- Expected collections
- €6,200.00
- Planned disbursements
- €3,100.00
- Forecast position
- €21,500.00
- Nature
- Software simulation
Accounts and IBANs
Give your clients’ flows an anchor point
The payment account and the IBAN can tie financial operations to the user company and to its space in your software. Their structure and assignment are defined according to the services, the users and the chosen framework.
An activation journey
The company reviews the applicable conditions, submits the required information and follows the verification journey before the relevant services are activated.
Contextualised movements
The software returns the available information on settlements, beneficiaries and operations by tying them to the company’s business objects.
Controlled access
Roles, viewing rights, permitted actions and validations are defined in line with the company’s organisation and the contractual perimeter.
A payment account is not presented as a bank account offering the full range of banking services.
Money in
Fit collection to the way your clients work
An ERP, an invoicing product and a service-management tool do not all trigger the same payments. The collection method and the expected data must match the real journey.
Incoming transfer
Associate settlement information with the invoice or the file. Available references and data feed tracking and reconciliation.
Card payment
A card journey can be assessed when the model, the users and the acceptance conditions allow it. Tracking must include failures, refunds and disputes.
Payment tied to a business object
Keep a stable identifier between the payment request, the invoice and the financial events. Operations with no match remain visible.
Money out
Tie a supplier invoice to an authorised payment
The software already holds useful data for preparing a settlement. Connecting it to the payment journey helps avoid re-keying, while keeping the required checks and validations.
Approved expense
The document and its amount are validated in the business workflow.
Checked beneficiary
The required details and information are verified.
Payment prepared
Amount, reference and any due date are presented.
Operation authorised
The authorised user completes the required authorisation actions.
Execution tracked
The journey takes the balance, controls and any rejections into account.
Situation returned
The software retrieves the available information and handles exceptions.
Preparing an order is not the same as executing it.
Data quality
Automate the reliable cases and keep control of the exceptions
Reconciliation associates a business fact with a financial movement. A usable reference improves that association; an identical amount is not always enough to identify the right invoice.
Examples of reconciliation rules in software
| Case encountered | Reading in the software | Handling to plan |
|---|---|---|
| Exact settlement | Invoice €2,480 and movement €2,480 with a consistent reference | Association according to the defined reliability rules |
| Partial payment | Invoice €2,480, received €1,480, remainder €1,000 | Keep the balance due and the history of movements |
| Grouped payment | Invoices €1,340 + €660 for a €2,000 settlement | Allocate only if the data support the association |
| Unidentified movement | Reference missing, ambiguous or inconsistent | Propose a review, without forcing the association |
| Refund or return | Financial event tied to a prior operation | Update the situation without erasing the audit trail |
Operational tracking
Present statuses that help the user and support
Separate what the software expects from what the infrastructure has actually confirmed. That split avoids confusing a settled invoice, an authorised order and an executed transfer.
Illustrative tracking view with fictional data
| Business reference | Amount | Situation shown |
|---|---|---|
| FAC-2026-084 | €2,480.00 | Movement received and matched |
| FAC-2026-085 | €2,480.00 | €1,480.00 received, €1,000.00 expected |
| FOU-2026-031 | €1,240.00 | Payment prepared, to authorise |
| Unallocated movement | €660.00 | To be reviewed by an authorised user |
Onboarding
Embed company verification in service activation
Opening payment services for a company involves a customer-knowledge journey, including KYB for the legal entity and KYC for the people concerned. The software can accompany the user and display progress through the journey.
Activation request
The company states its need and discovers the services offered.
Company information
Identity, activity and data useful to the file are collected.
People concerned
Representatives and beneficial owners are identified according to the applicable requirements.
Documents and checks
The required documents and planned controls are processed.
File review
A request for more information, a validation or a refusal may follow.
Activation and monitoring
The authorised services become available, with the required updates.
Signing up to the SaaS does not automatically mean acceptance of the payment services.
Product and economic model
Build a financial module whose usage can be measured
The value of the module is verified in your users’ tasks. The project must specify the need covered, the commercial conditions and the indicators that will decide the next stage of the rollout.
Usage and adoption
Track eligible companies, activation requests, complete files and the first collection. Separate software signup from the use of financial services.
Operational efficiency
Measure matched movements, exceptions, support requests and observed handling times. Set objectives from your starting situation.
Offer and monetisation
Assess an included module, an option or other contractual remuneration terms. Revenue, costs and any revenue share are negotiated according to the project.
Software concerned
Journeys adapted to each trade
The common point is a business object that precedes or explains the payment. The examples below describe integration paths to assess, without assuming each activity is eligible.
Invoicing and SME management
Tie customer invoice, collection, remaining amount due and reconciliation together.
ERP and company management
Connect customers, suppliers, approved expenses and financial movements.
Professional services
Attach deposits and balances to an assignment, an intervention or a file.
Construction and maintenance
Track settlements tied to a worksite or an intervention, with their references and business stages.
B2B commerce and distribution
Tie order, invoice, grouped settlement and amount allocation together.
Accounting and steering
Use the available movements and states in the tools of finance teams and authorised users.
API and embedded finance
Connect your product to the payment infrastructure
Your software manages business objects and the user experience. Payment.net and the interfaces made available for the project let these journeys connect to Tractial’s payment services.
Your B2B SaaS
- Clients and files
- Invoices and due dates
- User rights
- Screens and workflows
- Reconciliation rules
- Support and steering
APIs and interfaces
Tractial and Payment.net
- Payment accounts
- IBAN according to the model
- Incoming payments
- Authorised transfers
- Tracking information
- KYB and KYC journeys
The software must handle errors, duplicates, retries and gaps between its data and payment confirmations.
Progressive integration
From the first useful journey to a controlled rollout
A first, reduced perimeter makes it possible to check product usefulness and journey reliability before widening the functions or the user population.
Map the flows
Vendor and Tractial identify payers, beneficiaries, users, countries and exception cases.
Validate the model
Product, technical, operations and compliance teams define the perimeter and the responsibilities.
Prepare the integration
The vendor ties its business identifiers, rights and screens to the chosen interfaces.
Test the journeys
Teams check activation, payments, errors, duplicates, rejections and reconciliation.
Launch a pilot
An approved perimeter makes it possible to observe usage, reliability and support.
Extend according to the results
The parties adjust the product and validate the next rollout steps.
Choosing the model
Define the integration, the visibility and the responsibilities
The API describes the technical connection. Grey label and white label describe how the experience is embedded and how the parties are visible. Agent status frames a role in providing payment services. These dimensions can be combined according to the project.
API integration
You connect the chosen building blocks to your product. Screen choices and technical exchanges sit with the contractual split of roles.
See the pageGrey-label offer
A scoped journey can make a launch easier by relying on the offer and processes defined with Tractial. This approach can place more constraints on screens, notices, functions and how the product may evolve.
See the pagePayment institution agent
If the vendor’s role justifies it, an agent mandate can be assessed for certain activities carried out on behalf of Tractial. It involves governance, control and registration requirements before those activities are exercised.
See the page
Grey label and white label are not regulatory statuses. The payment-service provider’s role must remain identified in line with the applicable obligations.
Grey label and agent
Choose from the role your team wants to take on
Comparison of approaches according to the vendor’s role
| Scoping point | Scoped grey-label offer | Model with an agent mandate |
|---|---|---|
| Logic | Embed an offer and a journey defined with Tractial | Carry out the activities provided for by the mandate on behalf of Tractial |
| Launch | Can shorten some steps thanks to a scoped perimeter, with no guaranteed timeline | Also depends on formalities and preparation of the agent arrangement |
| User experience | Personalisation inside the agreed limits | Perimeter defined by the mandate, the controls and the technical choices |
| Regulatory role | Determined by the activities actually carried out, regardless of the commercial name | Activities covered by an applicable mandate and registration |
| Constraints | Screens, notices, journeys and changes potentially more tightly framed | Organisation, training, procedures, supervision and reporting to plan |
| KYB, KYC and monitoring | Task split and returns defined in the contract | Entrusted tasks and supervision specified in the mandate |
| Extensibility | Extensions subject to the parties’ agreement and the required validations | Changes to the mandate or the arrangement to assess according to the activities |
Framework and responsibilities
An embedded product with explicit roles
The financial integration must let the company understand who provides the software, who provides the payment services, and whom to contact depending on the request.
The software vendor
- Designs the product and the business journeys
- Manages its interfaces and the access that falls within its perimeter
- Ties documents and business references to operations
- Applies the tasks and obligations set out in the contract or the mandate
- Organises its support and the handling of requests with Tractial
Tractial
- Provides the payment services that fall within its licence and the validated perimeter
- Defines and implements the controls that fall within its responsibilities
- Reviews files according to the agreed arrangement
- Processes operations and returns the available information
- Frames supervision and any tasks entrusted to the partner
Invoice and payment
Complete your e-invoicing journey
If your software handles electronic invoices, the payment layer can complete that journey by tying the document, the settlement and the financial tracking data together. How this fits with the Accredited Platform, and each party’s responsibilities, must be defined.
Payment statuses and financial reporting do not replace the regulatory data and transmissions that belong to e-invoicing.
FAQ
What is embedded finance for a B2B SaaS?
It is the integration of financial services into software used by companies. A journey can tie invoice, payment account, IBAN, collection, transfer and tracking data together, according to the services chosen.
Is a licence required to embed payment services in software?
The role actually exercised must be analysed. Software can rely on a licensed provider within a defined framework; some activities involve an agent mandate or other requirements. Connecting to an API does not, on its own, determine the status required.
Can a payment account be offered to the SaaS’s company clients?
A payment account and an IBAN can be embedded according to the validated model. Assignment, account structure and accessible functions depend in particular on the company’s profile, the checks and the contractual conditions.
Can the embedded account complement accounts the company already uses?
The journey can be assessed as a complement to tools already in use. How the account is funded and how funds circulate are defined during scoping. A function that aggregates external accounts is not assumed.
Can we keep our existing invoicing module?
Yes, the project can start from your current module. Scoping must determine the identifiers, references, amounts, statuses and rules needed to tie your invoices to payment operations.
Is payment reconciliation always automatic?
No. Automation depends on the reliability of the data and the rules in place. Partial, grouped or ambiguous payments must be reviewable and correctable without losing their history.
Can suppliers be paid from the software?
A journey to prepare and authorise supplier payments can be assessed. Execution depends on the functions available, rights, controls and applicable authorisations.
Can a payment be scheduled to a due date?
This function must be confirmed for the chosen perimeter. Preparing or possibly scheduling a payment does not remove the authorisations, controls and execution conditions required.
How does company verification work?
The journey collects the information and documents needed to know the company, its representatives and its beneficial owners according to the applicable requirements. Additional items or a review may precede activation of the services.
What is the difference between grey label and agent status?
Grey label describes the experience and presentation of an offer. Agent status concerns activities carried out on behalf of a payment-service provider. The first does not rule out the second; the activities actually carried out determine the appropriate framework.
Does grey label allow a faster launch?
A perimeter and journey that are already scoped can simplify some steps. This approach can also limit personalisation and later changes. The timeline depends on the project and the required validations; no standard lead time is guaranteed.
Which payment data can be displayed in the SaaS?
The perimeter defines the information available, access rights and return conditions: operations, amounts, references or states, according to the interfaces chosen. Data must be shown only to authorised people.
How are the price and any vendor revenue defined?
Commercial conditions depend on the services, the users, the envisaged volumes, the payment methods, support and the integration model. The price of the module and any vendor remuneration are agreed in the contract.
How do you start a project with Tractial?
Show us your software, your company users, your flows, the countries involved, the envisaged volumes and the first journey to embed. That information makes it possible to assess the model, the responsibilities and the steps of a pilot.
Building blocks for your journey
Payment accounts and IBANs
Give your clients’ flows an anchor point.
See the pageIncoming and outgoing payments
Fit collection and transfers to the real journey.
See the pageKYC, KYB and compliance
Embed company verification in service activation.
See the pageAPI and integrations
Connect your product to the payment infrastructure.
See the pageWhite label and grey label
Define the integration, the visibility and the responsibilities.
See the pagePayment institution agent
Assess an agent mandate when the vendor’s role justifies it.
See the pageE-invoicing
Complete the invoice journey with the payment layer, without replacing the Accredited Platform.
See the pageYour software and Tractial
Which payment should your clients be able to track in your tool?
Show us your software, its users and the first financial journey you want to embed. We will assess the useful building blocks, the intervention model and the implementation steps with you.
Payment institution licensed by the ACPR, CIB 16748. Services subject to eligibility, compliance validation, contracting, technical availability and the applicable regulatory framework.