Business Central Integration Architecture: How Data Flows to Your ERP and Beyond

A Business Central integration architecture has three real building blocks: standard APIs for straightforward read and write access, Business Events for real-time reactions to what happens inside the ERP, and pre-built connectors for the integrations Microsoft or a partner has already solved. Most companies end up using all three, at different points, for different jobs. Knowing which one fits a given integration is the difference between a connector that survives an upgrade and a fragile script someone has to babysit.

This guide walks through how data actually moves in and out of Business Central: the three integration methods, a full reference architecture for the event-driven pattern (the one that scales), a worked example using VeriFactu, and the security model that has to sit underneath all of it.

The Three Ways Data Moves In and Out of Business Central

Method	Best for	Typical trigger
Standard APIs / OData	Pulling or pushing records on demand: reports, dashboards, batch imports	An external system asks for data
Business Events	Reacting immediately when something happens in BC: invoice posted, order shipped	An event fires inside Business Central
AppSource connectors	Common integrations someone has already built: Shopify, Salesforce, banking feeds	Installed and configured, not custom-built

APIs are pull-or-push and stateless: something asks Business Central for data, or sends data to it, over standard OData or the newer v2.0 API pages. They’re the right tool when an external system needs to query BC on its own schedule, or when you’re building a custom report or portal on top of ERP data.

Business Events flip that model: instead of something asking BC for data, BC tells the outside world when something worth knowing about has happened, in real time. That distinction matters more than it sounds. A nightly API pull means a bank reconciliation error, a stuck vendor invoice, or a failed VeriFactu submission sits unnoticed until the next batch job. An event-driven architecture reacts within seconds.

A Reference Architecture for Event-Driven Integration

Here’s the pattern we use for most Business Central integrations that need to be reliable, not just functional. Each numbered step corresponds to the diagram below.

1. Business Event fires. Something happens in BC, an invoice is posted, a purchase order is approved, that matches a subscribed event.
2. Power Automate or a Logic App picks it up. This is the automation layer: it receives the event payload and decides what happens next. Power Automate suits simpler flows; Logic Apps give you more control over retries, error branches, and enterprise connectors.
3. An Azure Function does the real work. Field mapping, currency conversion, validation, anything more complex than drag-and-drop steps comfortably handle belongs in code, not in a sprawling flow with forty actions.
4. A Service Bus queue sits in the middle. This is the piece most DIY integrations skip, and it’s the one that saves you at 2am. If the target system is down, the message waits in the queue and retries, instead of silently failing.
5. The message reaches its destination. A bank, a payroll provider, the AEAT for VeriFactu submissions, or a CRM like Dynamics 365 Sales, each with its own authentication and format.

Underneath all five steps sits one more piece that doesn’t show up as a box in most people’s mental model until something breaks: an Azure AD app registration securing every call between these components with OAuth 2.0, not a shared password sitting in a flow’s connection settings.

A Worked Example: Real-Time VeriFactu Submission

This pattern isn’t theoretical for Spanish businesses right now. Our guide to VeriFactu compliance in Business Central covers the regulation itself; here’s how the architecture above applies to it in practice.

An invoice is posted in Business Central. That posting fires a Business Event. A Logic App picks it up and calls an Azure Function, which builds the hash-chained, QR-coded record VeriFactu requires and signs it. The signed record drops onto a Service Bus queue rather than being sent directly, because the AEAT’s endpoint, like any government system, has moments where it’s slow or briefly unavailable, and a queued message retries automatically instead of vanishing. Once accepted, a second lightweight flow posts a confirmation back into Business Central and, optionally, pings the finance team’s Teams channel if anything was rejected.

The whole chain, from posting to confirmed submission, typically completes in under a minute, and every step of it is visible in Azure’s monitoring tools if something needs investigating.

Power Automate, Logic Apps, or Azure Functions: Where’s the Line?

The honest answer is that these three overlap, and teams waste time trying to find a hard rule where none exists. A rough guide that holds up in practice:

• Power Automate when a business user could plausibly build and maintain the flow, or when it’s mostly connecting Microsoft 365 services together. Our guide to automating workflows with Power Automate covers the patterns that work well here.
• Logic Apps when you need enterprise-grade error handling, run history retention, or connectors Power Automate doesn’t offer, and the flow is IT-owned rather than business-owned.
• Azure Functions when the logic is genuinely code: complex transformations, cryptographic signing, calls to libraries that don’t exist as connectors. Functions get called from a Logic App or Power Automate flow, not instead of them.

Most real integrations use two of the three together: a Logic App or Power Automate flow as the orchestrator, calling an Azure Function for the parts that need actual code.

The Security Model: Azure AD App Registrations

Every component in this architecture authenticates through an Azure AD (Microsoft Entra ID) app registration, not a personal login. That single decision avoids the most common integration failure we see: a flow built under someone’s individual account that stops working the day they leave the company or change their password.

The registration is granted specific API permissions scoped to what the integration actually needs, nothing broader, and authenticates using client credentials (a certificate or secret) rather than a username and password. Business Central’s admin center lets you see exactly which app registrations have access and revoke them individually, which matters when an integration is retired or a vendor relationship ends.

Common Integration Targets for Spanish SMEs

• Banking. Automated bank feed reconciliation, usually via a connector or a scheduled API pull rather than an event, since banks don’t push events to you.
• Tax and compliance. VeriFactu, SII, and Intrastat submissions: event-driven, because timing and reliability both matter.
• CRM. Syncing customers, quotes, and orders with Dynamics 365 Sales; often bidirectional, combining events on both sides.
• E-commerce. Order and inventory sync with Shopify or a marketplace, usually available as an AppSource connector rather than custom work.
• Payroll and HR. One-way feeds from payroll providers into BC’s general ledger, typically batch rather than real-time.
• Document management. Attaching quotes, contracts, and invoices to CRM and ERP records via SharePoint, covered in our guide to SharePoint Dynamics 365 integration.

Frequently Asked Questions

Do we need Business Central Premium for this kind of integration?

No. APIs, Business Events, and Azure integration work on Essentials as well as Premium; the licensing question is about which BC modules you’re integrating with, not the integration architecture itself. Azure resources (Functions, Logic Apps, Service Bus) are billed separately, usually a small monthly cost for typical SME transaction volumes.

How long does an integration like the VeriFactu example take to build?

A single well-scoped event-driven integration, one trigger, one destination, typically takes two to four weeks including testing. Complexity comes from the destination system’s requirements (like VeriFactu’s signing rules), not from the Business Central side, which is usually the easy part.

Can this architecture work with an on-premises Business Central?

Business Events and the modern API surface are strongest on Business Central online. On-premises deployments can still integrate via web services and OData, but real-time events require more setup, and it’s one more reason on-premises versions are increasingly worth reconsidering, as covered in our Business Central vs Dynamics 365 Finance comparison.

What happens if the external system is down when an event fires?

This is exactly what the Service Bus queue in the reference architecture solves. The message waits and retries on a backoff schedule rather than being lost, and if it fails repeatedly it lands in a dead-letter queue where someone gets alerted instead of the failure going unnoticed.

Getting Started

If you’re planning an integration and not sure whether it needs a simple API call or the full event-driven architecture, start by asking one question: does the outside world need to know within seconds, or is a daily sync good enough? That answer alone rules out half the options. AlishBit designs and builds Business Central integrations for businesses across Spain and Europe, from a single API connection to full event-driven architectures like the one above.