QuickBooks Transaction Status Counts Did Not Update During a Submit

This article covers the live progress counts on the QuickBooks Transaction Status panel - the Run History table with its Total, Processed, Success, Failed and Status columns - and why those counts sometimes sit still for one user while the submit is running perfectly well in the background.

Questions this answers

• "A QuickBooks sync progress popup never showed up for one of our bookkeepers even though the sync ran - where would that have failed?"

This article is only about the live progress display on the Transaction Status panel. If a specific deal or commission did not reach QuickBooks at all, that is a different problem - see the article on deals and commissions that do not post.

There is no separate progress popup

Worth clearing up first, because it changes what you are looking for. DeskManager Online does not throw up a progress window of its own when a QuickBooks submit starts. Progress appears as live updates to a row inside the Transaction Status panel, which you open yourself from the QuickBooks screen.

The panel shows Last Run at the top and then Run History (Latest 50): one row per submit, with the run's date, the Total it is working through, how many it has Processed so far, the Success and Failed counts, an overall Status of Success, Partial or Failed, the type of run, and a message.

While a submit is running, the Processed count on that run's row ticks upward and, when it finishes, the Success, Failed and Status cells fill in - provided the panel is open in front of you and the live connection is working.

Why the counts can stay frozen

The submit itself and the live progress updates travel by two different routes. The submit runs on the server and finishes whether anyone is watching or not. The progress updates are pushed separately to one browser session - specifically, the session belonging to the person who started the submit.

That design produces several ways for a bookkeeper to see nothing:

• They did not start the run. Progress is only pushed to the person who kicked it off. A scheduled or automatic run, or one another user started, will not update anyone else's screen live.
• They signed in somewhere else. Only the most recent sign-in for that user is treated as the live session. Signing in on a second computer, or in a second browser, sends the updates to that one instead.
• The tab was closed, reloaded, or the machine slept after the submit started. The live connection goes with it, and the updates have nowhere to land.
• The network blocks the live connection. Some office firewalls, proxies and VPNs block the persistent connection this uses while leaving normal page loads working, so everything else in DeskManager Online feels fine.

In every one of those cases the submit still runs and still writes its results. Only the live display is affected.

Nothing tells you a progress update was lost

If a progress update cannot be delivered, the failure is recorded internally for AutoManager support and that is the end of it. The user is not warned, the run is not stopped, nothing is rolled back, and the update is not sent again later. From the bookkeeper's side it simply looks like nothing happened.

This is deliberate - a failed status update must never be allowed to interfere with the accounting submit itself - but it does mean a silent progress display is not evidence of anything.

How to check what actually happened

Do not judge a run by the live counts. Read the record instead.

1. Open the QuickBooks screen and choose Transaction Status.
2. Check Last Run at the top for the date and time of the most recent submit.
3. Find the run in Run History (Latest 50) and read its row: Total, Processed, Success, Failed and Status.
4. A Status of Partial or Failed means some transactions did not post; the Message column and your failed transactions list tell you which.
5. If the row shows Processed equal to Total and a Status of Success, the submit completed regardless of what the screen did at the time.

Closing and reopening the Transaction Status panel reloads it from the server, so it is always the reliable view.

Troubleshooting checklist

1. Confirm the bookkeeper is the person who started the run. If not, that alone explains it.
2. Have them sign out everywhere else and sign back in on the one machine they will watch from.
3. Have them open Transaction Status before starting the submit and leave the tab in front, not minimised or reloaded.
4. Try once from a different network - a phone hotspot is a quick test - to rule out a firewall or proxy blocking the live connection.
5. Whatever the live display does, verify the outcome from Run History afterwards.

When to contact support

Contact support if the live counts never move for any user at your dealership even on a run they started themselves with the panel open, or if a run's row in Run History stays stuck part-way through and never reaches a final status. Give them the date and time of the run.