Dynamics Community Forum Thread Details

Business Central as financial backend for external procurement system – any major blockers?

Hi,

I’m currently evaluating a potential architecture where Microsoft Dynamics 365 Business Central would be used mainly as the financial backend, while our own procurement system handles the purchasing workflow.

I do not have hands-on experience with Business Central yet, but I’m a senior software developer working on the procurement platform and I’m used to designing and implementing integrations and distributed system architectures.

The intended setup is roughly:

Our procurement system handles:
- purchase requests/orders
- account coding/dimensions
- approval workflows
- supplier communication/order dispatch
Business Central handles:
- purchase order registration
- AP / vendor ledger
- invoice matching
- bookkeeping
- payments
- financial reporting

Planned integration flow:

BC exposes master data to our procurement system (we may fetch it trough the API):
- chart of accounts
- dimensions
- projects
- vendors
A fully approved and coded purchase order is exported from our procurement system to BC via API.
Optionally, goods receipt / delivery confirmation is also exported from our procurement system to support 3-way matching.
Supplier invoices are sent directly to BC and matched against the imported purchase orders.

The goal is to keep BC as close to standard as possible and avoid heavy ERP customization.

My questions are mainly:

Does this architecture align well with how BC is intended to be used?
Are there any major blockers or pain points around:
- purchase order APIs
- dimensions/account coding
- goods receipt handling
- invoice matching
- external system ownership of procurement workflows?
Is there anything in BC’s purchasing model that makes this approach problematic in practice?
Would standard APIs normally be enough, or does this typically require custom AL development?

Any experiences, warnings or recommendations would be highly appreciated.

Categories:

Dynamics 365 Business Central

Hello,

Yes, this architecture is generally fine: let your procurement system own requisitions, approvals, supplier communication, and coding, then send the approved PO into Business Central as the financial source of truth for receiving/invoicing/AP/payment/reporting. The main thing is to respect BC’s purchasing model instead of treating it like a generic ledger API: create real Purchase Orders + Purchase Order Lines, use BC vendors/items/G/L accounts/dimensions, send receipts only if BC should know goods were received, and let invoices match against those PO/receipt lines. Standard REST APIs cover a lot: vendors, accounts, dimensions, purchase orders, purchase order lines, purchase invoices, receipts, and attachments; but in practice I would expect some custom AL API pages/codeunits if you need stricter validation, idempotency, custom PO status mapping, complex dimensions, project/job-specific logic, automatic matching/posting, or a clean “one call creates full coded PO” endpoint. Biggest warnings: decide one system of ownership for PO changes, don’t bypass BC dimensions/account validation, test 3-way matching early, and be careful with advanced warehouse, item tracking, prepayments, item charges, projects/jobs, subcontracting, blanket orders, and intercompany because matching/auto-receipt has limitations there.

Regards,
Oussama Sabbouh

Quick Links

Leaderboard > Small and medium business | Business Central, NAV, RMS