Moving from Dynamics GP to Business Central? Don't Overlook Your Payment Processes

A GP-to-BC migration is an opportunity to rethink how accounts payable works, but only if payment requirements are considered early enough in the project. 

For organizations moving from Microsoft Dynamics GP to Dynamics 365 Business Central, much of the migration conversation naturally centers on data, configurations, integrations, and getting the new ERP ready for business. 

But there's another important consideration: What happens to the processes people have relied on for years? 

Accounts payable (AP) is a good example. Over time, GP users often develop highly specific routines for building payment batches, managing approvals, printing checks, and coordinating payments across companies. Some of these processes are supported by third-party solutions or customizations. Others depend on knowledge that lives primarily with the people doing the work. 

When those organizations move to Business Central, they may discover that familiar payment processes don't translate directly into the new environment. 

That's not necessarily a problem. In fact, it creates an opportunity to evaluate what the organization actually needs from its payment processes rather than simply recreating what it had before. 

For Microsoft Partners and implementation teams, understanding those requirements early can help avoid surprises and support a smoother transition. 

Why Payment Processes Deserve Attention During a GP-to-BC Migration 

It's easy to underestimate how much operational knowledge is built into an established GP environment. 

Consider a typical payment run. An AP team may know exactly how to select invoices, create batches, route payments for approval, print checks, and handle exceptions. They may also have specific controls governing who can access certain checkbooks, approve payments above a particular threshold, or use authorized signatures. 

Some of these requirements are documented. Others may have evolved through years of experience, workarounds, and incremental changes. 

The challenge is that Dynamics GP and Business Central are not feature-for-feature equivalents. Even when the business outcome remains the same, the steps and tools used to accomplish it may be different. 

This distinction matters during discovery and solution design. 

Rather than asking, "How do we recreate this GP process in Business Central?" a more useful starting point is, "What does this process need to accomplish, and what's the best way to support it in Business Central?" 

That question can reveal opportunities to simplify workflows, eliminate unnecessary steps, and introduce automation where it makes sense. 

Five Payment Process Areas to Evaluate Before Migration 

While every GP environment is different, several areas deserve particular attention when planning how AP will operate in Business Central. 

1. Payment Selection and Batch Management 

For many AP teams, the payment run is one of the most familiar parts of their GP environment. 

Depending on how GP has been configured, teams may use native functionality, third-party tools, or established procedures to select invoices, build payment batches, and move payments through the process. 

In Business Central, payment preparation typically centers on payment journals and the Suggest Vendor Payments functionality. Organizations moving from GP should expect differences in how payments are selected, organized, and managed. 

This is a good opportunity to evaluate whether the existing process is still the most effective approach. 

For example, does the AP team need to manually coordinate every payment run? Are there recurring steps that could be scheduled or automated? How much visibility does the team need into payment status and outstanding tasks? 

Solutions such as Mekorma Payment Hub can extend Business Central's native payment functionality, while scheduling capabilities can help automate recurring payment activities. 

The goal should be to design a process that supports the organization's needs, not necessarily to preserve every step from GP. 

2. Payment Approvals and Internal Controls 

Approval workflows can be especially important to examine because the requirements may be more complex than they initially appear. 

A GP environment might include multiple approval levels, dollar thresholds, approver groups, company-specific rules, or exceptions for particular payment scenarios. 

For organizations using Mekorma Workflow in GP, those workflows should not be assumed to transfer directly into Business Central. Approval requirements need to be evaluated and redesigned within the Business Central environment. 

The distinction between the existing workflow and the underlying business requirement is important. 

For example, a rule requiring additional approval for payments over $50,000 may still be necessary. However, the way that rule is implemented and how approvers interact with it may change. 

During discovery, partners should look beyond the visible workflow configuration to understand the controls it supports. 

Who needs to approve payments? Under what circumstances? What happens when an approver is unavailable? What audit history does the organization need to retain? 

Understanding these requirements helps ensure that important controls are preserved, even when the approval process itself changes. 

3. Security and Separation of Duties 

Security is another area where GP configurations shouldn't be treated as a direct blueprint for Business Central. 

In GP, access may be governed by company-specific settings, checkbook permissions, payment responsibilities, and third-party security configurations. 

Business Central uses a different security model, so those requirements need to be mapped to the new environment. 

Consider an AP employee who is responsible for preparing payments from a particular bank account but should not have authority to approve or release them. 

The underlying requirement is separation of duties. The specific GP permissions used to enforce that control are less important than ensuring the appropriate restrictions exist in Business Central. 

This is why security planning should focus on roles, responsibilities, and business risks rather than simply trying to replicate existing permission settings. 

4. Check Printing and Bank Requirements 

For organizations that still issue checks, printing requirements can be one of the more visible challenges during migration. 

Over time, GP check layouts may have been customized to include specific signatures, MICR placement, logos, remittance details, custom fields, or bank-required formatting. 

Those layouts may not transfer directly to Business Central and could need to be rebuilt or replaced. 

It's important to distinguish between requirements that must be preserved and preferences that can be reconsidered. 

Bank-required MICR placement, authorized signatures, and other essential controls must work correctly. But does every field need to appear in exactly the same location as it did on the GP check? 

Not necessarily. 

Partners should help clients identify their non-negotiable requirements while remaining flexible about layout details that are simply familiar. 

Check printing also deserves sufficient time for configuration and testing before go-live. Discovering a critical printing or bank compatibility issue at the end of a migration project can create unnecessary disruption. 

5. Multi-Company Payment Management 

Organizations managing payments across multiple companies face another set of considerations. 

In GP, each company may have its own bank accounts, checkbooks, payment methods, security rules, and approval requirements. 

Some organizations handle these activities independently for each company, while others use shared services functionality to centralize payment operations. 

Business Central introduces a different environment for managing company-specific processes, making this a useful time to reassess how work is coordinated. 

For example, if an AP team supports ten companies, does it make sense to continue managing payment runs separately for each one? Could a more centralized approach reduce repetitive work while maintaining the appropriate company-level controls? 

Mekorma Shared Services is one option for supporting centralized, multi-company payment operations in Business Central. 

Regardless of the solution, partners should understand how the organization manages payments across entities today and whether that approach will continue to meet its needs. 

Not Every GP Customization or Third-Party Tool Needs a Direct Replacement 

A GP environment that has been in place for many years often reflects layers of decisions made at different points in the organization's history. 

A customization may have been introduced to address a limitation in GP. A third-party solution may have been added to support a particular workflow. A manual process may have developed because it was the easiest way to manage an exception. 

Those decisions may have made sense at the time, but they don't automatically need to be carried forward. 

Business Central offers different native capabilities, and the broader solution ecosystem provides additional options for organizations with more specialized requirements. 

Some existing needs may be handled natively. Others may require a different configuration, additional functionality, or a redesigned process. 

The key is to understand why a tool or process exists before deciding whether to replace it. This approach can help prevent unnecessary complexity and avoid rebuilding limitations or workarounds that no longer apply. 

It also creates an opportunity for partners to have a more strategic conversation with clients about how AP could operate in the future. 

Make AP Process Discovery Part of Migration Planning 

One of the most valuable things implementation teams can do is involve the people who actually manage payments in the discovery process. 

Documentation and system configurations provide important information, but they don't always tell the full story. 

AP employees often know where exceptions occur, which tasks require extra attention, and which controls are essential to keeping payments moving. 

Their experience can reveal requirements that might otherwise be missed. 

A practical discovery conversation should explore: 

These conversations help distinguish between business requirements and familiar ways of working. 

They can also help implementation teams identify areas that require additional configuration, testing, training, or change management before go-live. 

A Successful Migration Doesn't Have to Look Like GP 

For organizations that have spent years working in Dynamics GP, familiarity can be reassuring. But familiar processes aren't necessarily the best fit for a new ERP environment. 

Moving to Business Central provides an opportunity to carry forward the knowledge, controls, and requirements that matter while reconsidering how the work gets done. 

For Microsoft Partners, that means helping clients look beyond a feature-by-feature comparison and focus on the outcomes their processes need to support. 

And for AP teams, it means recognizing that a different workflow doesn't have to mean losing control or starting over. 

The most successful approach is to preserve what matters, rethink what doesn't, and build payment processes that support the organization in its new Business Central environment. 

At Mekorma, we work with Microsoft Dynamics Partners and organizations navigating the transition from GP to Business Central, with a particular focus on payment processes, controls, and automation. Learn more about Mekorma Payment Hub for Business Central and how it supports payment operations within the ERP.