A stuck batch in Dynamics GP can bring your posting process to a halt and create real delays for your finance team. Whether you see errors in the Batch Recovery window, posting interruptions, or a batch that won’t release from printing or editing status, the root cause is often tied to user disconnects, transaction issues, or background locks. This guide walks you through the most common reasons batches get stuck and the steps you can take to recover them safely. If you run into something unexpected, our team works with these issues every day and can help you get back on track quickly.
Possible causes of a Stuck Batch.
- This occurs when a user posts and either Dynamics GP freezes or their computer loses connection with the server.
We also see batches get stuck when users do not sign out of Dynamics GP properly. Sometimes, a user will click the red X in the top right corner of the Dynamics GP window while still having other windows open. This can cause batches to show as “Marked” for posting. Before you leave, close all windows and save any open documents. Then, click the Microsoft Dynamics GP button and select Exit. - Temporary loss of internet connection.
- Corrupt or Duplicate Records
- Transaction Errors
- Closed Fiscal Periods
- Unmatched Distributions
- Missing Required Information
- Not enough user permissions to post
Normal Batch Status
A batch in GP typically is has two statuses.
- No transactions
- Available
Error messages possible
- Batch Failed to complete posting. Use batch recovery window to complete the posting process
- Your previous transaction-level posting session has not finished processing
- Data entry errors exist in the batch. Use the batch recovery window to process.
- Example below
The batch will usually be in the following statuses
- Posting
- Printing
- Busy
- Marked
- Edited
- Locked
- And others
Go to Batch Recovery
Dynamics GP -> Tools -> Routines -> Batch Recovery
In some cases, a batch in the Batch Recovery Window will indicate the issue. These would include but are not limited to:
- Marked
- Posting Interrupted
- Journal Printing Interrupted
- Transaction error-Edit Required
- Example below
You should be able to click continue. If the batch goes away you should now be able to access it in the module the batch originated in.
Choose the batch. Then click the Print button to print a Batch Edit List.
Search for error messages within the Edit List, which will indicate the necessary actions to correct it.
Next, open the transaction with the error, make the necessary corrections, and you should be able to post the batch.
If you mark the batch and hit continue and receive an error that says the batch is Busy, Marked, or Posting you still have as stuck batch.
Example
There are a few reasons at this point you may have an issue still.
- Connection issues
- Missed processing windows behind other windows.
- Not exiting Dynamics GP properly
There are a few potential problems
- Stuck user in tables
- Transaction errors in batch posting
- Both will need to be resolved in SQL by someone with the proper knowledge of Dynamics GP Tables
Reasons for stuck user are improperly exiting or being disconnected. Dynamics GP has the following tables that may associate the user with the batch if not disconnected properly.
Dynamics.Activity
Dynamics.SY00800
Dynamics.SY00801
Tempdb.Dex_Session
Tempdb.Dex_Lock
If the user is logged out you can run the following scripts to get out of the batch being edited by.
delete from tempdb..DEX_SESSION where session_id not in (select SQLSESID from DYNAMICS..ACTIVITY)
delete from tempdb..DEX_LOCK where session_id not in (select SQLSESID from DYNAMICS..ACTIVITY)
delete from DYNAMICS..SY00800 where USERID not in (select USERID from DYNAMICS..ACTIVITY)
delete from DYNAMICS..SY00801 where USERID not in (select USERID from DYNAMICS..ACTIVITY)
If this does not resolve the issue you may have to look at these tables individually. I usually remove DEX_LOCK then DEX_SESSION first followed by SY00801 table entry then followed by SY00801 and finally Activity. IF you are not familiar with these tables you should not do this. You can have all users exit and backup the database. Then you can delete for the tables where user is not equal to the user you are logged in as.
You may now update the batch table to access the batch.
- UPDATE SY00500 SET MKDTOPST=0, BCHSTTUS=0 where BACHNUMB=’XXXXXX’
The other is you could have is transaction errors.
- When Dynamics GP posts it first copies records from the SQL (Work or Open) tables to (Open or History) tables. Next Dynamics GP goes back and deletes information from the original table. When a batch gets stuck it is very much where it got stuck in the process. This should be addressed by an experienced Dynamics GP Consultant.
Crestwood Associates consultants are experienced in these matters and available to help.
Ready to Move Beyond GP Login Issues?
Explore your GP modernization options with Crestwood Associates today.
Get Your Free ERP Assessment | Explore Our Services | Learn More About Crestwood
Connect With Us: X | LinkedIn | Contact Us
More Resources: Acumatica ERP | Business Central | Blog Home
© 2025 Crestwood Associates. All rights reserved.


