AP Invoice Capture in BC: Native Extension vs Portal

There is a pattern that repeats across many invoice capture software implementations in mid-sized companies: the tool lives outside the ERP, in a standalone web portal that the accounts payable team logs into every morning to review, validate, and then “push” invoices into the ERP through an integration. The integration runs over an API. The API breaks from time to time. When it breaks, someone keys invoices in manually so the month-end close keeps moving. And about 18 months in, the finance leadership team discovers the external system has stopped delivering on its promise.

This pattern is not accidental. It is the natural outcome of deploying a tool whose architectural model is designed to live apart from the ERP and to connect with it through an external integration. There is another way of doing this that structurally avoids these problems: a native AL extension that lives inside Business Central itself.

The difference between the two approaches is not academic. It has very concrete consequences on operational reliability, latency between capture and posting, maintenance cost, and what happens when Microsoft ships a new version of Business Central every 6 months.

What it means to “live inside Business Central”

Microsoft Dynamics 365 Business Central has a native extension system written in AL, the ERP’s own programming language. An AL extension is developed, published on AppSource (Microsoft’s official marketplace) and installed directly into the customer’s tenant like any other Business Central feature.

Once installed, the extension:

• Uses existing Business Central tables and master data (vendors, accounts, dimensions, posting profiles).
• Uses the ERP’s native flows (approval workflows, bank reconciliation, ledgers and journals).
• Inherits permissions from Business Central’s role-based security model.
• Updates automatically from AppSource when Microsoft releases a new version of the ERP.
• Never exposes data outside: all processing happens inside the customer’s cloud environment.

An external solution, by contrast, is a standalone system that captures invoices in its own backend, displays them in its own portal, and “sends” them into Business Central through a REST API. That API is a bridge the customer has to keep alive.

Five practical differences

At the technical-operational level, the two architectures diverge on five points:

1. Reliability across Business Central updates. Microsoft releases a major version of Business Central every 6 months (Wave 1 in April, Wave 2 in October). Each release introduces changes to APIs, endpoints and data structures. A native AL extension upgrades alongside the ERP automatically from AppSource: Microsoft guarantees that certified extensions keep working. An external API integration requires the external software vendor to update its connector before the customer upgrades BC. If it does not arrive on time, the customer is stuck on an old ERP version or with a broken integration.

2. Latency between capture and posting. With a native extension, the invoice is captured, processed with OCR + AI, matched against its receipt and posted within the same second, inside the same data engine. With an external solution, the invoice is captured in the external portal, stored there, waits for the sync job to run (typically every 5-15 minutes or in an overnight batch), gets pushed via the API into BC, and only then gets posted. That latency breaks real-time bank reconciliation because by the time the bank statement arrives, not all payments may have been posted yet.

3. Single vendor master. With a native extension, the vendor shown in the captured invoice is the same record as the vendor in Purchasing, in Payments, in the expense account. There is one single master. With an external solution, the external system has its own vendor master that gets synchronized with BC’s master. Any divergence (a new vendor added on one side, a bank account change on the other) turns into a mismatched invoice that someone has to fix manually.

4. Native approvals. Business Central has a powerful workflow engine that approves invoices by amount, by vendor, by cost center, by dimension, by user. A native AL extension uses that engine: when an invoice enters the system, it triggers the corresponding workflow and approvers sign off from the Business Central mobile app. An external solution typically ships its own approval system inside the external portal, which forces the team to log into a separate tool to approve (more friction, lower adoption) and requires maintaining two parallel role systems.

5. Auditability and compliance. When an auditor requests the trail for a specific invoice, with a native AL extension the entire trail lives inside Business Central: who captured it, when, which OCR processed it, who approved it, on what date it was posted, against which purchase order it was matched. With an external solution, part of the trail lives in BC and part in the external system, and reconstructing the history requires querying two systems and reconciling them. For ISAE 3402 audits, SAF-T (Portugal), IRAP/SOX (US subsidiaries) and similar regulatory frameworks, the difference is operationally substantial.

What an external solution actually costs

There is a hidden cost in external solutions that very few finance leaders quantify before signing: the annual cost of keeping the integration alive.

Every Business Central update (every 6 months) can break or degrade the integration. Every change in the external portal (every 3-6 months) can have side effects on the data flow. Every time the customer’s IT team changes something in the environment (a certificate, a security policy, a tenant migration), the integration needs review.

In practice, companies running external solutions end up spending 30-60 hours per year keeping the integration alive: regression testing after every release, escalating incidents between two vendors (the external software provider and the BC partner), ad-hoc patches, manual workarounds when something fails.

At blended internal + external rates, that adds up to EUR 2,000-5,000/year of recurring “invisible” cost that never appears in the original proposal but shows up year after year. A native extension does not carry that cost because updates are automatic and the responsibility sits with Microsoft + the extension publisher.

What makes a good native extension

Not all AL extensions in AppSource are equal. Three technical criteria separate a genuinely good extension from an integration disguised as an extension:

1. Is the extension Microsoft-certified (Co-sell ready / AppSource Certified)? AppSource only lists extensions that have passed Microsoft’s technical validation. Private extensions (installed as .app files by the partner) do not carry that guarantee.

2. Does it use BC’s existing master tables, or does it create its own parallel tables? A good extension adds tables only for genuinely new functionality (for example, an OCR capture log) but reuses standard masters (vendors, accounts, dimensions, posting profiles). A poorly designed extension creates parallel tables that duplicate existing information.

3. Does it also work for companies that are not yet on Business Central? A well-architected extension should be able to operate as a standalone system or connected to another ERP through controlled integrations, for customers in transition to BC. This is not contradictory with being a native extension: it is an additional abstraction layer that gives the solution a longer useful life.

The right question before choosing

When a company running Business Central evaluates an invoice capture tool, the question is not only “which one has the best OCR?” or “which one is cheaper?”. It is:

“Will this solution still be working exactly as well 3 years from now, after 6 Business Central updates, 5 external portal version changes and a couple of tenant migrations?”

If the reasonable answer is “yes, without intervention”, you are looking at a native AL extension. If the answer is “it depends on both vendors keeping the integration alive”, you are looking at an external dependency that will cost recurring time and money.

For an organization already running Business Central and planning to stay, choosing an external solution when a native option exists generates technical debt from day one.

In summary

• External capture solutions live in a separate portal and connect to Business Central through an API. That API is a bridge that needs to be kept alive every 6 months (every BC update).
• A native AL extension lives inside Business Central, uses existing masters and workflows, updates automatically from AppSource and requires no integration maintenance.
• 5 practical differences: reliability across BC updates, latency between capture and posting, single vendor master, native approvals, consolidated auditability.
• External solutions carry a recurring “invisible” cost of EUR 2,000-5,000/year in integration maintenance that never appeared in the original proposal.
• A good native extension meets 3 criteria: Microsoft-certified (AppSource Certified), reuses BC’s standard masters, and can also run standalone or with other ERPs.
• For companies already on BC, choosing external when a native option exists is generating technical debt from day one.

---

Looking for an invoice capture tool that lives inside Business Central as a native AL extension? dvinvoice-hub is published on AppSource, reuses BC’s existing master data, triggers native approval workflows and updates automatically with every ERP release. It can also run standalone or with other ERPs if you are not on BC yet. Calculate your block or book a demo.