System integration: connecting invoicing, CRM and ERP

System integration means that data moves between your invoicing software, CRM, ERP and bank without anyone retyping it. There are five common patterns: direct API calls, webhooks, scheduled sync, file exchange and middleware. The choice comes down to two questions: how fresh the data has to be, and who notices when something gets stuck.

This article is about connecting the systems inside a company. We have covered the path of an online order to the invoicing software separately: e-commerce automation from order to invoice.

API calls: when you need the answer now

One system queries or writes to another through its programming interface (API) and gets an answer at once. Számla Agent, from the Hungarian invoicing service Számlázz.hu, works this way: the sender posts the invoice data as XML in an HTTP POST request, and the service generates the document and returns the PDF.

An API call works well when the next step of the process waits for the answer. But if the other side is slow or unreachable, the caller has to decide what happens to the request.

Webhooks: when the other system calls you

With a webhook you do not ask at regular intervals. Instead, the source system calls an address you provide whenever something happens. A CRM can call when a new customer is added, for instance, and a payment provider when a payment succeeds.

According to the HubSpot documentation, notifications are not guaranteed to arrive in the order the events occurred, nor is it guaranteed that you get only one notification per event. Stripe says the same, and asks for the endpoint to respond quickly and run any slow processing afterwards.

Both providers sign their notifications. Without verification, anyone can send a fake event to the endpoint and trigger a process with it.

Scheduled sync: when hourly or daily is enough

Here a scheduled job fetches the changes at set intervals and carries them over. It is simpler to build and to debug, but in exchange the data is typically one scheduling cycle behind.

It is a good choice for reports, master data reconciliation and overnight closing. The job should only fetch the items changed since the last successful run, and if a run overruns, the next one should not start alongside it.

Plan for rate limits too. Many APIs signal too many requests with status code 429, and may use the Retry-After header to tell you how long to wait before the next request.

File exchange: the language of banks and older systems

Many systems still export and import data as files: CSV exports, XML, bank statements. Bank statements even have an international standard: according to the Dutch Payments Association, camt.053 is a message format within the ISO 20022 standard for the digital exchange of daily bank statements.

With file exchange, decide up front how you will recognise a file you have already processed. If the same statement is imported twice, the credits can show up twice in the ERP.

Bank data via API: with consent and within limits

Bank account data can also be reached through a third party. Under Article 67 of the PSD2 directive, an account information service provider may provide its service only with the explicit consent of the payment service user, and may access information only from designated payment accounts.

If an integration uses this route, keeping track of consents is part of the process, not a one-off setting.

Middleware: when several systems talk to each other

With three or four systems, point-to-point connections quickly become hard to follow. With middleware, each system talks only to one central service, which transforms, queues and forwards the data.

Stripe also recommends processing incoming events from an asynchronous queue, because a sudden spike can overwhelm the endpoint. The advantage of middleware is that logging, retries and failure alerts live in one place. The drawback is that it becomes a system you have to run as well.

Protecting against duplicate runs

When the network fails, the sender cannot tell whether its request arrived. According to RFC 9110, a client should not automatically retry a request with a non-idempotent method unless it knows that repeating it has the same effect as a single run, or that the original request was never applied.

In invoicing, a blindly repeated request can mean two invoices. Stripe solves this with an idempotency key: a request repeated with the same key gets the result of the first request back and does not create a new object.

For webhooks, Stripe recommends logging the IDs of the events you have processed and not processing those again. The same rule works in every integration: every item needs a unique identifier.

Example: Hungary's NAV Online Invoice system

The interface specification of the Hungarian tax authority (NAV) shows what to prepare for. Invoice data is processed asynchronously: a submission returns a transaction ID, and reporting is not complete until the client has received the acknowledgement for that invoice.

No response within 60 seconds does not mean the submission failed. According to the specification, an accepted solution is for the invoicing software to wait 5 minutes, list its recent transactions, and resubmit only if none is unknown.

The NAV says this is lawful only without human intervention, with scheduling done by software logic. Each request also has a unique identifier (requestId), and a successfully processed request’s ID cannot be reused for the same taxpayer.

Error handling: retries and alerts

A temporary error, such as a timeout or overload, calls for a different response than a content error, such as a missing tax number or a wrong format. The first is worth retrying with growing pauses, the second needs a person to look at it.

Webhook providers work this way themselves. In live mode Stripe retries delivery for up to three days with exponential backoff, and HubSpot up to 10 times within 24 hours.

Whatever still fails after the retries should not disappear silently. Put it on a separate error list and notify someone who can make a decision.

Logging: what to record, and what not to

For every run it should be clear when it happened, in which system, who started it, which item it concerned and what the outcome was. The OWASP logging guidance is built on the same four questions: when, where, who, what.

The same guidance lists what should not be recorded directly in logs: access tokens, passwords, database connection strings, encryption keys, bank account and payment card data, sensitive personal data. This is a common mistake in integrations, because logging the full request is convenient.

Ownership: who owns the integration?

An integration lives on the border between two systems, so it easily ends up with no owner. The invoicing provider is responsible for its side and the CRM vendor for theirs, but nobody is responsible for the process between them until you assign someone.

Put it in writing: who gets the failure alerts, who can access the logs, who rotates expiring keys, and who tests the connection when one of the systems is updated.

How to get started

1. Process map: which data goes from where to where, how often, and who uses it.
2. Pattern choice: API or webhook for an immediate answer, scheduled sync for daily freshness, file exchange where only an export exists.
3. Duplicate protection: a unique identifier for every item, and a check before writing.
4. Error list and log: with alerts, and without secrets.
5. Owner and testing: a named owner, and tests with faulty and duplicate data too.

If you would rather not build it yourself

Brauniq also works on business process automation and on connecting systems, and design, development, operation and support stay in one hand with us. If you would like to see how this could look at your company, take a look at our process automation service.

Sources

• NAV Online Invoice: interface specification and developer documentation, v3.0 (12 February 2026), NAV GitHub repository (in Hungarian)
• Számlázz.hu: How does Számla Agent work?
• HubSpot Developers: Webhooks API
• Stripe: Receive Stripe events in your webhook endpoint
• Stripe API: Idempotent requests
• RFC 9110, HTTP Semantics, 9.2.2 Idempotent Methods
• RFC 6585, 4. 429 Too Many Requests
• Directive (EU) 2015/2366 (PSD2), Article 67
• Betaalvereniging Nederland: camt.053
• ISO 20022: Bank-to-Customer Cash Management message set
• OWASP Logging Cheat Sheet