GP Payables Functionality You'll Need to Rebuild When you Move to Business Central
If you are currently using Microsoft Dynamics GP, odds are your company has had it for years and has developed it and customized it in ways that will have to be rebuilt in D365 Business Central.
If you are an Accounts Payable pro and your organization is planning a GP to BC Migration, this post is for you. We will discuss the out of the box functionality of Business Central and the common gaps users experience when moving from a stalwart and highly customized GP environment, to a new BC environment.
Business Central’s Super Powers Come from Outside BC
Business Central is not a standalone product. Many of its most promoted capabilities depend on other Microsoft services working alongside it.
- Approval workflows that go beyond basic routing rely on Power Automate.
- Robust financial reporting and dashboards that match what GP users have built over time often require Power BI.
- The Payables Agent, which Microsoft positions as an AP automation solution built into BC, runs on Copilot Studio, requires a linked Power Platform environment, consumes Copilot Credits billed separately on a pay-per-use model, and currently only fully supports English in a limited number of locales.
These are not features that come out of the box with a BC license in the traditional sense. They are features that come out of the Microsoft ecosystem, which is a meaningful distinction when a budgeting, planning a go-live, or evaluating whether BC alone solves your AP problem.
Approval Workflow
GP users spend years building approval logic across email threads, ERP settings, and institutional knowledge. None of it migrates to BC. The result is invoice holds, single-person bottlenecks, and manual email approvals until someone rebuilds the workflow from scratch. It's one of the most common post-go-live frustrations users experience.
Check Printing
BC handles check printing differently than GP, and users often don’t find out until they need to run a check run. Custom check stock, familiar layouts, and established processes will need to be rebuilt.
ACH Payment Setup
BC's native ACH capabilities don't match what GP users might have set up. Many need a third-party solution to replicate their existing payment process.
Multi-Entity AP Breaks Down Fast
Multi-entity AP requires careful setup in BC and often additional tooling. Invoices hit the wrong entity, approval routing ignores company boundaries, and payment runs create accounting headaches.
Invoice Capture
BC's native invoice capture is limited and requires a Payables Agent to work in any meaningful way, and even with the Payables Agent it will likely fall short of expectations for Multi-Entity or larger businesses. Users who have relied on a more robust OCR or scanning workflow in GP will likely find BC has no magic bullet here. Without a dedicated AP automation tool, manual data entry is usually required to fill these gaps in BC.
Conclusion
A GP to BC migration is not a straight lift-and-shift, and BC is not a self-contained replacement for everything GP users have built over years. Many of BC's most promoted capabilities depend on Power Automate, Power BI, Copilot Studio, and other Microsoft services that come with their own setup requirements, licensing, and costs. Understanding that distinction before go-live is the difference between a migration that meets expectations and one that generates a long list of surprises.

