BaaS integration with an ERP means your accounting or resource planning system talks directly to a regulated account and payment infrastructure. Payments go out from the ERP, statements and incoming transfers come back, and nobody re-keys data or uploads files by hand. For a Lithuanian company, the practical questions are which kind of API you need, what the ERP must be able to read and send, and how to roll the connection out without disrupting payments.

This guide covers those questions in order. It is written for finance leaders, founders and advisors at SMEs, e-commerce and cross-border businesses who want their bank layer to behave like a module of their ERP.

Demivoltdemivolt.comConnect Business Payments to Finance WorkflowsDemivolt provides business accounts, SEPA and SWIFT payments, and multi-account tools for companies managing cross-border operations.Explore Demivolt

TL;DR

PSD2 open banking APIs and premium business APIs are different tools. PSD2 covers account information and payment initiation; ERP automation at volume usually needs a dedicated channel.
A good integration covers four flows: payment initiation, status feedback, statements and reconciliation, and master data such as accounts and users.
Model your fees before you build. On Demivolt, SEPA Out is 0.40 € per transfer and SWIFT Out is 30.00 €, which makes batching and routing decisions measurable.
Roll out in stages: one account, test payments, parallel reconciliation, then full cut-over with approval roles set in both systems.

What BaaS integration with an ERP actually means
PSD2 APIs versus premium business APIs
The technical choices that shape your project
Lithuanian specifics: e-invoicing and SEPA
What to automate first
Modeling the cost of integrated payments
A rollout plan that avoids disruption
Common mistakes
Our perspective on ERP and banking integration
Where Demivolt fits
FAQ
Sources

What BaaS integration with an ERP actually means

Banking-as-a-Service (BaaS) lets a regulated provider expose accounts, payments and cards as infrastructure that other software can use. In an ERP context, that infrastructure becomes part of your finance workflow rather than a separate website your accountant logs into.

A working integration usually has four parts:

Payment initiation. Approved supplier invoices, payroll and refunds are turned into payment instructions and sent from the ERP.
Status feedback. The ERP learns whether each payment was accepted, rejected or is still pending, so open items are not guessed.
Statements and reconciliation. Incoming and outgoing transactions flow back and are matched to invoices automatically.
Structure and control. Accounts, sub-accounts, users and approval rights in the ERP mirror those at the account provider.

If one of these four is missing, finance staff fill the gap manually, and that is where errors and delays come from.

PSD2 APIs versus premium business APIs

Many SMEs assume that because PSD2 guarantees open access to bank data, ERP integration is already solved. It is only partly true.

The Bank of Lithuania describes open banking as an API-based concept for sharing the financial information needed to build financial products and services. It also maintains a public register of regulated third-party providers. PSD2 access is designed for account information and payment initiation by those providers, which gives you a baseline of interoperability.

The Euro Banking Association’s working group on corporate open banking draws a useful line between compliance-led and business-led APIs. Regulatory APIs satisfy interoperability requirements. Business-led, premium APIs are built to remove manual intervention, lower operational risk and enable real-time reconciliation inside the ERP or treasury system. For workloads with bulk payments, high transaction counts or real-time cash visibility, the second type is the one that matters.

Criterion	PSD2 / open banking API	Premium business API or host-to-host channel
Purpose	Regulatory access for third-party providers	Operational automation for corporate clients
Typical use	Account aggregation, single payment initiation	Bulk payments, automated reconciliation, ERP or treasury workflows
Access model	Through registered or authorized providers	Service agreement with the account provider
Throughput	Not designed for heavy batch workloads	Built for volume and speed
Best for	Light integrations, early-stage automation	Finance teams with recurring, high-volume flows

If you want a Lithuania-specific view of the regulatory side, our article on launching open banking integration in Lithuania without licensing delays walks through it.

The technical choices that shape your project

Direct connection or middleware

The European Banking Authority keeps clarifying PSD2 API issues raised by industry participants, precisely because technical implementations differ from bank to bank. For an SME, the practical consequence is that every additional bank connection is another interface to build, test and maintain. Experts commonly advise using established API partners or a central layer to reduce that complexity.

That argues for consolidating where you can. If your operating accounts, payments and cards sit with one regulated provider, your ERP needs one integration rather than three.

Data formats

Most ERP-to-bank traffic in Europe is built on ISO 20022 messages: payment instructions, status reports and account statements. Whatever channel you use, confirm with your provider which message types and which version it accepts, and compare that to what your ERP vendor supports. A mismatch here is the most common cause of delay in integration projects, and it is cheap to check before you start.

For context on how ERP vendors are approaching this, see our news item on a Nordic ERP firm partnering on ISO 20022 compliance.

Security and access

Treat the integration as a privileged user. Give it only the permissions it needs, keep credentials and certificates in a managed store, and rotate them on a schedule. On the account side, role-based user management lets you separate who prepares a payment, who approves it and who only views balances. The same separation should exist inside the ERP, so that approval limits do not depend on a single system.

Lithuanian specifics: e-invoicing and SEPA

SABIS and the invoice-to-payment chain

Lithuania’s invoice administration system SABIS (Sąskaitų administravimo bendroji informacinė sistema) is managed by the National Centre of Shared Functions and has operated since 2024. Businesses that invoice the public sector exchange e-invoices through it. The same source notes that the Euroconnector tool helps companies connect SABIS to their internal accounting and ERP software.

The Ministry of the Economy and Innovation presented the move as an upgrade that makes sending and receiving electronic invoices simpler for the public sector, businesses and other contracting entities. For your finance stack, this matters because an e-invoice that enters the ERP automatically can drive a payment proposal, which then flows to your account provider, and returns as a reconciled statement line. Each link in that chain is easier when the bank layer is integrated rather than manual.

SEPA behavior and cut-off times

The Bank of Lithuania’s SEPA overview lists the schemes in operation: SEPA Credit Transfer, Core Direct Debit, B2B Direct Debit and SEPA Instant Credit Transfer. It also notes that standardized technical interfaces between banks and enterprises’ account systems let companies streamline internal payment processes.

When your ERP schedules payments, it should know the provider’s cut-off times. A payment released a few minutes late can slip a business day. Our guide to SEPA cut-off times and avoiding D+1 delays in Lithuania explains how to build that into payment runs.

What to automate first

Not every flow deserves the same priority. A sensible order is:

Statement import and reconciliation. Lowest risk, because nothing leaves your account. It proves the data mapping works.
Supplier payment runs. Start with SEPA payments, which are the most uniform.
Payroll and recurring payments. Add after supplier runs have been stable for a few cycles.
International payments. SWIFT instructions carry more data and more exceptions, so they come later.
Card expenses. Feed card transactions into the ERP for coding and approval.

For card spend, virtual and physical business cards can be issued per team, project or vendor subscription, and each card’s transactions then map cleanly to a cost center. Our card programmes page describes the options.

Modeling the cost of integrated payments

Automation changes behavior. When payments are cheap to send and easy to approve, teams send more of them, so unit fees matter. These are the fees we publish for Demivolt business accounts:

Item	Fee
Account opening	0
Account verification	0
Dedicated Client Manager	0
Monthly maintenance	0 per month
Account closure	0
Internal transfers between Demivolt accounts	0
SEPA In	0 €
SEPA Out	0.40 € per transfer
SWIFT In	25.00 €
SWIFT Out	30.00 €

A simple worked example: a company that releases 200 SEPA supplier payments a month pays 200 × 0.40 € = 80.00 € in outgoing SEPA fees, and 0 € for the incoming SEPA payments from customers. The same company sending 4 SWIFT payments pays 4 × 30.00 € = 120.00 €. Seeing this in a spreadsheet before go-live shows whether routing a payment over SEPA instead of SWIFT, where the currency and destination allow it, is worth building into your ERP rules. You can run your own numbers with the SEPA fee calculator.

Because internal transfers between Demivolt accounts cost nothing, multi-account structures also work well for intercompany flows, such as moving funds from a collection account to an operating account for a group of companies.

A rollout plan that avoids disruption

Map your processes. List every payment type, who approves it, which ERP module creates it and how it is reconciled.
Define the account structure. Decide which accounts hold which flows, for example collections, operations, payroll and tax. Dedicated IBANs make it easier to attribute incoming money to a business unit or customer segment.
Confirm formats and channel. Agree message types, authentication and environments with your provider and ERP vendor in writing.
Build in a test environment. Run sample payments and statements, including rejections, returns and duplicate files.
Reconcile in parallel. For one or two cycles, reconcile both automatically and manually, and compare the results.
Cut over in stages. Start with one entity or one payment type. Keep approval roles identical in both systems.
Monitor. Review failed and pending payments daily for the first month, then weekly.

If you also link accounts held elsewhere, our practical guide to linking business bank accounts in Lithuania covers the setup.

Common mistakes

Using PSD2 access for bulk workloads. It works in a demo and struggles at month-end volume.
Ignoring status messages. If the ERP only sends and never reads rejections, unpaid invoices look paid.
Skipping idempotency. Retried files should never create duplicate payments. Ask how your provider and your ERP detect repeats.
Over-broad credentials. One shared admin key for everything makes audit trails useless.
Treating compliance as separate. Segregated client funds, risk-based onboarding and transaction monitoring are part of the provider’s regulated obligations, and your ERP workflows should leave room for the reviews they can trigger.

Our perspective on ERP and banking integration

We see the integration question from the account provider’s side, and a few patterns repeat.

First, the biggest gains come from reconciliation, not payment sending. Finance teams that get clean, structured statements into the ERP every day close the month faster and spot problems earlier.

Second, fewer connections beat more connections. A regulated platform that combines business accounts, SEPA and SWIFT payments and cards behind one set of roles and one integration is simpler to maintain than several separate bank relationships. That is the logic behind our Banking-as-a-Service offering for companies and fintechs that want this infrastructure inside their own products.

Third, transparency is a feature. Fixed, published unit fees let a CFO forecast payment costs, and a dedicated client manager at no charge means integration questions go to a person who knows your setup.

Finally, compliance is not an obstacle to automation but the condition for it. Our onboarding is risk-based and runs on EU regulatory standards, and we design flows so that checks happen without stalling routine payments.

— dd

Where Demivolt fits

If you are planning an ERP connection, start with the account structure. Demivolt business accounts give your company dedicated IBANs, multi-account structures and role-based access with segregated client funds. Payments covers SEPA and SWIFT, and cards can be added for expenses. Account opening carries no fee. To discuss which integration approach suits your ERP, get started with Demivolt and tell us your system, your payment volumes and your timeline.

Advisors who implement ERP systems for clients can also review the partner and white-label models.

FAQ

Do I need a premium API, or is PSD2 access enough?

For occasional payments and basic balance visibility, PSD2 access through a registered provider can be enough. For recurring bulk payments and automated reconciliation, the EBA working group’s analysis points to business-led APIs as the better fit. Estimate your monthly payment count and reconciliation effort, then decide.

How long does an ERP integration take?

It depends on your ERP, the number of entities and the payment types in scope. A statement-import pilot can be far quicker than a full payment-and-approval workflow. Agree a staged plan with your ERP vendor and your account provider rather than a single go-live date.

Can one integration cover several accounts and users?

Yes, if the provider supports multi-account structures and role-based user management. Define in advance which accounts the ERP can see and which users can approve payments, and keep those rules identical on both sides.

What does it cost to send payments from the ERP?

On Demivolt, account opening and monthly maintenance are 0, SEPA Out is 0.40 € per transfer and SWIFT Out is 30.00 €. Incoming SEPA is 0 € and incoming SWIFT is 25.00 €. Your ERP vendor may charge separately for its connector, so confirm that with them.

BaaS Integration With ERP: A Guide for Lithuanian Companies