Your systems in — and kept in sync.
ERP, accounting, CRM, bank, credit agencies and credit insurers all deliver into the same record. Connect over the REST API, the batch interface or file handover — with public documentation, and the first transfer is possible the same day.
Connect the way your IT actually works.
Not every organisation can serve an API, and not every one wants to push files. Both routes lead into the same record, and neither is the second-class one.
REST API, OData & SAP BTP
Read and write debtors, documents and payments, authenticated by token. For SAP landscapes also over OData and the SAP Business Technology Platform. The documentation is public — your IT can review it before anything is signed.
Batch interface
For regular bulk handover from the ERP: whole populations rather than single calls, at whatever cadence your source system supports.
File handover
Where a technical connection would take months, operations start with files — and replacing them later changes nothing about the processes above.
Public documentation, open for everyone to read.
The first transfer is possible the same day. What takes longer afterwards — field mappings, company codes, special cases — we work through with you rather than handing it over as a project.
All integrations included. Maintenance too.
A connection is only a connection if it is still right tomorrow. Changes flow into the record continuously, and webhooks report them back to your systems instead of waiting for the next nightly run. When a source system changes, we keep the connection working — that is part of the platform, not a separate line item.
What a connection transfers is your decision. The integration layer grants no permissions: what a user or an agent sees afterwards follows the roles in Bilendo, not whatever an interface happened to deliver.
- Inbound
- New documents, payments and master-data changes from your source systems.
- Outbound
- Webhooks report what happened in Bilendo to the systems that need to know.
- Visible
- Each connection shows in the interface when it last synchronised.
The connected systems, and which of them are publicly documented.
The directory of existing connections — ERP and accounting, credit agencies, credit insurers and banking. Anyone looking for their own provider finds it here, or sees which generic route is left for it.
- SAP (ABAP) ERP Guide
- SAP (OData) ERP Guide
- DATEV Accounting Guide
- FibuNet Accounting Guide
- Allianz Trade Credit insurer Guide
- Atradius Credit insurer Connection
- Coface Credit insurer Connection
- Creditreform Credit agency Guide
- Creditsafe Credit agency Connection
- CRIF Credit agency Connection
- Dun & Bradstreet Credit agency Connection
- Bureau van Dijk Credit agency Connection
- and many more Open the integration portal
And the generic routes everything else comes in on
- REST API
- SFTP file exchange
- Webhooks
- CSV import
"Guide" means the connection is publicly documented in the integration portal, so your IT can review it before anything is signed. A provider missing from this list is not an exclusion — over the REST API and file handover, any system that releases its data can be connected.
No second system to reconcile.
Bilendo is not a second set of books. What arrives becomes the one debtor record that dunning, clarification, credit decisions and every agent work from — so there is nothing that could drift apart between two systems.
What that record looks likeWhat the integration layer explicitly does not do.
Here too, the list of promises not made is the fastest way to judge the rest.
- No SDK. There is a documented REST API, not a library we maintain for you.
- No migration of your ERP. Bilendo reads from it and writes back; it does not replace it.
- No connection without released data. Where a source system releases nothing, no interface helps.
- No silent field mappings. What lands in which field is agreed, not guessed.
- No extended rights through the interface. Permissions come from the roles in Bilendo.
- No substitute for the data-processing agreement — a connection starts with it, not after it.
What IT wants to know before rollout.
The first transfer is possible the same day, because the documentation is public and there is no approval of ours in front of it. What takes time afterwards are field mappings and the special cases of your system landscape — not access.
No. The connection uses the routes your ERP already has — API, batch handover or file. Bilendo reads from it and writes back; it does not take the place of your accounting and requires no change in the source system.
No, and that is deliberately stated. There is a documented REST API with token authentication; a library we would maintain for six languages does not exist. Anyone expecting one and not finding it has a problem — which is why it is written here.
Through webhooks. They report events to the address you register, so your systems do not have to poll for changes. For each connection, the interface shows when it last synchronised.
No. A connection delivers data into the record; who sees it afterwards is decided by the roles and data scopes in Bilendo. An agent, too, reads only what the person it runs for may see — the interface changes nothing about that.
Yes, they are part of the same layer. Reports, cover and limits arrive through the existing connections and land on the debtor rather than sitting in a portal next to it. Which providers those are today is named above.