Moving from Dynamics GP to Business Central: What Changes for Your Payment Process

For many organizations, the decision to leave Microsoft Dynamics GP for Business Central is made at the ERP level. The day-to-day impact, though, lands on the people who run the processes. Few teams feel that more directly than the ones responsible for getting vendors paid. 

Payment teams on GP have often spent years refining how they work. They know how a payment run comes together, how checks are configured and printed, who signs off on what, and how to handle the exceptions that inevitably come up. Some of that knowledge lives in documentation. Much of it lives in people's heads. 

Migrating means giving up some of that familiarity, and that can feel like a step backward. It isn't. The team already understands what has to happen, which controls matter, and what keeps payments flowing. Business Central may change the steps, but it doesn't erase that understanding. 

The outcome stays the same; the path changes 

The most significant changes in a GP-to-Business Central move tend to be about how work gets done rather than what needs to be accomplished. A payment run in Business Central still ends with vendors paid accurately and on time. The route to get there, however, may look quite different. 

Those differences typically show up in four areas: how payments are built and managed, how approvals are routed, how security is structured, and how checks are laid out and printed. Organizations running multiple companies or bank accounts should also expect changes in how that work is coordinated. 

This is especially true for GP environments that have evolved over a long time. A current process might depend on a third-party add-on, a customization, or simply habits the team developed along the way. That history is valuable because it shows what the organization actually needs, but the GP setup shouldn't dictate exactly how those needs are met in Business Central. 

Building and managing payment runs 

The payment run is often the first place Business Central feels different. 

In GP, teams usually have an established rhythm for selecting invoices, building payment batches, and moving them through to completion. Many use add-on tools to support that routine. Mekorma Action Board is one example. 

In Business Central, payment building starts from the native Suggest Vendor Payments functionality. Add-ons can extend that foundation. Action Board, for instance, is available in Business Central and builds on the native process. Even so, teams should expect the experience to differ from what they knew in GP. 

Recurring payment processes are also worth revisiting. Business Central's Job Queue Entries can be used to schedule routine steps in the payment run, which may reduce some of the manual coordination teams currently handle by hand. 

Approvals get redesigned, not transferred 

Approval requirements don't go away in Business Central, but the mechanism behind them usually does change. 

GP users who manage payment approvals through an add-on may have built out detailed approval levels, dollar thresholds, approver groups, and exceptions. Organizations should plan to rebuild those approvals within Business Central's workflow framework rather than expecting the GP configuration to carry over directly. 

The business rules themselves remain the guide. If the policy is that payments over $50,000 require an additional approver, that rule should shape the new workflow. Approvers may review and sign off through a different path, but the oversight the organization depends on can be preserved. 

Security is structured differently 

Long-time GP users should also expect to rethink payment security. 

In GP, add-on security settings may govern which checkbooks a user can access, which signatures they can apply, what they can approve, and which tasks they can perform, often configured separately for each company. 

In Business Central, that setup won't transfer as-is. Consider a user named Jane who prepares and processes payments for specific companies. In Business Central, her ability to do that work is determined by her permission sets and standard payables permissions. Approval authority is handled separately through Business Central approval workflows. The result is a clean separation: Jane can prepare payments without automatically receiving approval rights she shouldn't have. 

Your checks probably won't be identical 

Check printing is one of the most visible changes a payment team will encounter. 

GP check layouts have often been customized over many years, with specific signatures, MICR line placement, logos, remittance details, custom fields, and bank-driven requirements. In Business Central, those layouts typically need to be rebuilt or replaced. The usual approach is to start from the closest supported layout and modify it to meet the organization's requirements. 

That means the new check may not be a pixel-for-pixel match with the old one, and that's often fine. Some requirements are non-negotiable, such as the MICR placement your bank specifies or internal signature thresholds. Others, like a field appearing in a particular spot because that's where people are used to seeing it, may not be consequential. 

Organizations that print checks should budget extra time here. Layouts, signatures, remittances, MICR requirements, and printer behavior all need to be reviewed and tested before live checks go out. 

Multi-company payments need a fresh look 

Teams paying vendors across several legal entities are used to switching between companies and tracking each one's requirements. 

In GP, every company may have its own checkbooks, bank accounts, payment methods, security rules, check layouts, and signature requirements. Some teams handle that one company at a time. Others use shared services tools to centralize payments across entities. 

Those company-specific requirements still apply in Business Central, but managing them day to day will likely change. Centralized, multi-company payment processing is possible in Business Central, whether through add-ons that provide a single place to build and process batches across authorized companies or through other approaches. The underlying concept carries forward even though the setup and user experience look different. Whether an organization manages two companies or twenty, the team should expect a period of adjustment. 

Don't hunt for a one-to-one replacement for every GP tool 

A GP migration is a chance to look at the full payables cycle, not just replicate the existing technology stack. 

It helps to separate the cycle into its parts. Invoice processing (capturing, coding, and approving vendor invoices) and payment processing (building, approving, and releasing payments) are often handled by different tools. In GP, organizations may have stitched these together with a mix of add-ons, customizations, and manual steps. 

In Business Central, the same needs may be met differently. Native functionality covers part of the process. Invoice processing solutions such as Continia, or Microsoft's own tools like the Payables Agent, can handle invoice capture and approval. Payment processing solutions can then extend Business Central's native payment capabilities with the workflows, controls, and efficiencies payment teams rely on. Paired together, these can support a complete, end-to-end process. 

Rather than searching for a direct replacement for every GP tool, start by identifying which processes the team needs to preserve, which ones need improvement, and which ones should be rethought entirely. From there, the organization and its Microsoft partner can decide on the right mix of native functionality and extensions. 

Bring the knowledge, not the baggage 

Moving from GP to Business Central takes time, and it will introduce unfamiliar steps, particularly for teams that have spent years getting comfortable in GP. But those teams also bring something valuable: a deep understanding of the controls, requirements, and processes that keep payments moving. 

Don’t try to recreate GP inside Business Central. Some tasks that felt like second nature in GP may simply not make sense in the new environment. Instead, treat the migration as an opportunity to carry forward what works, change what doesn't, and settle into a payment process built for where the organization is headed.