Your accounts payable team runs the same check batch process every pay cycle. It used to take thirty seconds. Now it takes five minutes. Nothing obvious has changed, the system hasn't thrown any errors, and yet the slowdown gets a little worse each month.
If you're running EFT payments through Microsoft Dynamics GP and this sounds familiar, the problem almost certainly lives in a single database table called PM20100. And the fix takes about five minutes once you know where to look.
Why Does the Dynamics GP PM20100 Table Cause Check Batch Slowdowns?
To understand the problem, it helps to understand what PM20100 is designed to do. It's a remittance holding table: a temporary staging area where Dynamics GP stores details about which invoices are being paid before printing that information on a check stub. The table was built around an assumption: every payment eventually results in a printed check, and the act of printing clears out the remittance records.
EFT payments broke that assumption. When a vendor payment goes out electronically, GP still creates remittance records in PM20100 exactly the same way it would for a paper check. But because there's no check to print, there's no print event to clear those records out. They just stay there.
The result compounds over time. Every pay cycle adds another batch of remittance records to the table. When your team goes to build a new check batch, GP has to scan through all of them to determine what needs to be included. Fifty records is fast. Three hundred is noticeable. A thousand is the kind of slowdown that sends someone to Google looking for a new ERP system.
What Setting Is Actually Causing the PM20100 Records to Accumulate?
The culprit is a checkbox in the Select Checks window called "Print Previously Applied Documents." When this option is enabled, GP creates remittance records in PM20100 for every payment, whether or not the payment will ever result in a printed document. For check payments, this works correctly because the print event clears the records. For EFT payments, it creates an ever-growing backlog.
Here's what drives me crazy about this: it's entirely silent. No warning, no error, no performance alert. The checkbox is enabled by default, EFT payments are increasingly standard, and the two interact in a way that nobody designed anyone to notice until the slowdown becomes impossible to ignore.
How Do You Fix Slow Dynamics GP Check Batch Processing?
There are two fixes, and you should do both. The first stops new records from accumulating. The second prevents the problem from coming back.
Fix 1: Uncheck the setting during batch creation.
When building your next check batch in the Select Checks window, find the "Print Previously Applied Documents" checkbox and uncheck it. That's the entire fix for new batches. With the setting off, GP stops creating remittance records in PM20100 for your EFT payments. Nothing accumulates; nothing slows down.
Fix 2: Change the default so it stays off.
Unchecking it manually each time works, but it relies on whoever builds the batch to remember. The more durable solution is to change the default in Payables Setup, so the checkbox comes pre-cleared every time. Here's how:
- Go to Microsoft Dynamics GP > Tools > Setup > Purchasing > Payables.
- Find the default settings for check processing.
- Set "Print Previously Applied Documents" to unchecked.
- Save the change.
Every new check batch will now start with the correct setting automatically. The manual memory requirement is gone.
What If the PM20100 Table Already Has Thousands of Stuck Records?
Changing the checkbox setting prevents new records from piling up, but it doesn't clear the ones already there. If you've been running EFT payments with this setting enabled for months or years, GP is still wading through a backlog every time you build a batch. Fixing the setting helps going forward, but the existing records are still slowing things down.
Clearing stuck PM20100 records requires direct SQL work against the database. Done correctly, it removes only the orphaned remittance records without touching legitimate payment history. Done incorrectly, it can create data integrity problems you don't want. This isn't a task to run from a forum script without understanding what you're deleting.
If you're dealing with significant existing slowdowns after correcting the setting, that's the signal that your PM20100 table needs to be cleaned up by someone who knows the GP data structure. The fix is reliable and not complicated for an experienced GP consultant, but it does require a careful hand.
Is This Problem Worth Fixing on a System Approaching End of Life?
It's a fair question. Microsoft has confirmed that Dynamics GP reaches end of life in December 2029, and many GP customers are somewhere in the process of evaluating migration options. So why invest time in optimizing a system you may be leaving?
The answer depends on your timeline. A well-planned migration from GP to a modern cloud platform typically takes six to twelve months from evaluation to go-live. Organizations that start serious evaluation in 2026 or 2027 are in a comfortable position. Ones that wait until 2028 or 2029 are in a different situation entirely.
In the meantime, there's no reason to tolerate avoidable performance problems in a system your team uses every pay cycle. A five-minute fix that gets check batch processing back to thirty seconds is worth doing regardless of what comes next. Your AP staff shouldn't be losing time to a fixable setting while migration planning runs in the background.
For GP customers thinking through migration options, both and are worth evaluating. Both are cloud-native, actively developed, and built to handle the payables workflows GP customers rely on.
Frequently Asked Questions About Dynamics GP Check Batch Performance
Does unchecking "Print Previously Applied Documents" affect what prints on EFT remittances?
No. EFT remittances are generated and delivered through a separate process from the check batch creation setting. Unchecking this option affects only whether GP creates records in the PM20100 staging table. Your vendor remittance notifications are not impacted.
How do I know if PM20100 is the cause of my slowdown and not something else?
The clearest indicator is that the slowdown is progressive and correlates with payment volume. If batch creation has gotten slower every month and you're running a significant volume of EFT payments, PM20100 accumulation is the most likely cause. A GP-experienced consultant can query the table directly to confirm record counts and advise on next steps.
Can I clear PM20100 records myself with a SQL script?
Technically, yes. Practically, it depends on your comfort level with GP's database structure and your ability to verify that you're targeting only orphaned remittance records. If you're not certain what you're deleting, reach out to a qualified GP support resource rather than running an untested script against a production database.
Still Dealing with GP Performance Issues?
If your check batch slowdown persists after correcting the setting, or if you want help clearing existing PM20100 records safely, the team at CAL Business Solutions can help. to talk through your specific situation.
CAL Business Solutions is an Acumatica and Microsoft Dynamics 365 Business Central implementation partner serving distribution, manufacturing, brick & block, and professional services businesses across the United States. CAL has supported Microsoft Dynamics GP customers for over 40 years and continues to provide GP optimization, support, and migration planning services.
