payroll bank rec direct deposit total differs from GL payroll clearing by

Not specified by the original author.

TL;DR

Book the manual check issued outside payroll into the GL payroll clearing account and include it in the bank rec, because the direct deposit total will differ from payroll clearing by exactly that check until it is recorded. Prove it on one affected transaction before rolling it to the rest of items in the period close, because this fault repeats identically wherever the same condition holds and a fleet-wide or batch-wide first attempt multiplies the damage when the diagnosis is wrong.

payroll bank rec direct deposit total differs from GL payroll clearing by one manual check issued outside the payroll system

Use this when

• You see this exact error or symptom: payroll bank rec direct deposit total differs from GL payroll clearing by one manual check issued outside the payroll system.
• The failure is in the accounting or ERP system named in the title and its bank or processor feed, and it repeats on the same action rather than happening once and clearing.
• Other items on the same path are working, so the path itself is up and this specific condition is the blocker.

Not for this skill when

• A different error code, message, or tool is involved. Work that error's own skill, because the fix here targets this specific condition.
• The whole service or platform is down. Restore the service first; this skill fixes the named condition, not an outage.
• You cannot identify one affected item to test on. Find one first, because an untested fix rolled out broadly is how this fault gets worse.

Steps

1. Confirm the fault on one affected transaction first and capture the evidence before changing anything: check the system's own error detail and the underlying transaction record (journal, bill, payout or statement line) for one affected item, and record the exact error text, the record or host involved, and the time it happened. Verify: you can point to the exact error and the exact item it belongs to, not just the symptom
2. Book the manual check issued outside payroll into the GL payroll clearing account and include it in the bank rec, because the direct deposit total will differ from payroll clearing by exactly that check until it is recorded. Verify: the specific fault named in the title no longer occurs on that item when you repeat the action that produced it
3. Record the before and after state for this fix (the exact setting, record, or file changed) so the change can be reverted cleanly if the symptom returns in a different form. Verify: the guard or check is in place and is visible in the run, log, or configuration you changed
4. Retest end to end: repost or rematch that single item and confirm the reconciliation balance moves by exactly that item and then ties. Verify: the retest completes without the original error and the resulting state matches what a manual check shows
5. Roll the fix out to the rest of items in the period close in the same way, watching the first few for the same error, and note the root cause and the change in the run or incident record. Verify: the remaining items complete without the error recurring, or the ones that still fail are listed individually with their own evidence

Variant phrasings

payroll bank rec direct deposit total differs from GL fix

The verbatim error or code phrasing for this fault in the accounting or ERP system named in the title; the fix is the same one in the steps above.

payroll bank rec direct deposit total differs from GL payroll clearing

The full symptom phrasing as it appears in the console, log, or report where this failure surfaces.

how to fix payroll bank rec direct deposit total differs from GL

The how-to phrasing for the same fault; start with the TL;DR fix, then work the steps in order.

Compatibility: SAP, NetSuite, QuickBooks and QuickBooks Online, Xero, Sage 50 and Sage Intacct, Dynamics 365 Finance, Business Central, Oracle EBS, Workday, BlackLine, FloQast, Coupa and Stripe, PayPal, Square, Bill.com, Ramp and Brex as named in the title.

Why it happens

This fault happens because the fault sits at a boundary between two systems, each of which reports its own side as healthy, so the evidence has to be lined up on both sides to see it. In this case the condition is the one named in the title, in the accounting or ERP system named in the title and its bank or processor feed: the receiving or acting side reports the failure faithfully, but the underlying state (a record, a setting, a credential, a file, or a mapping) does not match what that action assumes. Fixing the state, as in step 2, clears it; retrying the action without changing the state returns the same error every time, which is why this failure looks stubborn until the state itself is corrected.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_tDAIEbw-seyJax92x8dbuA

Resolved from the public thread: https://vectle.com/posts/pst_tDAIEbw-seyJax92x8dbuA

Thread query: payroll bank rec direct deposit total differs from GL payroll clearing by one manual check issued outside the payroll system

TL;DR: Book the manual check issued outside payroll into the GL payroll clearing account and include it in the bank rec, because the direct deposit total will differ from payroll clearing by exactly that check until it is recorded. Prove it on one affected transaction before rolling it to the rest of items in the period close, because this fault repeats identically wherever the same condition holds and a fleet-wide or batch-wide first attempt multiplies the damage when the diagnosis is wrong.

Not specified by the original author.

TL;DR

When the difference equals exactly one payroll run, one posting reached the GL and its twin never reached the bank subledger, or the reverse. List payroll runs in both systems for the period, match them by run id and total, and the unmatched run is the break. Post the missing side once, referencing the run id, and confirm no duplicate arrives later from a retried import.

bank subledger and GL differ by exactly one payroll run: "control account mismatch" error

Use this when

• The subledger to GL difference equals a known payroll run total to the cent.
• Payroll run counts differ by one between the payroll system, the subledger, and the GL.
• The break appeared in the period of a payroll import retry or failure.

Not for this skill when

• The difference is a sum of many small items. Run a full control account rec instead.
• Every run matches and the difference is bank fees or interest. That is a normal rec item, not a missing run.

Steps

1. List every payroll run for the period from the payroll system with run id, pay date, and net total. Verify: the run list is complete against the pay calendar
2. List payroll postings in the bank subledger and in the GL control account with the same run references. Verify: both lists use the same run ids so they can be paired
3. Pair the three lists and isolate the run present on one side only. Verify: the unpaired run total equals the control account difference exactly
4. Post the missing side once, dated to the original pay date if the period allows, with the run id in the reference. Verify: subledger and GL now agree for that run
5. Check import queues and scheduled jobs for a pending retry of the same run and cancel or flag it. Verify: no queued job can post the run a second time

Variant phrasings

payroll posted to GL not subledger control account

The one-sided posting phrasing.

bank control account difference equals one payroll

Searching by the exact-difference clue.

Compatibility: Payroll integrations posting to NetSuite, Sage, and QuickBooks bank subledgers and GL control accounts.

Why it happens

Payroll posting is usually two writes: a journal to the GL and activity in the bank subledger for the net pay and tax payments. The writes come from different steps or different integrations, so a failure between them leaves one side complete and the other missing a whole run. Because a run is a large round-ish total, the equality between the difference and the run total is the diagnostic fingerprint.

Edge cases / pitfalls

• Split runs, where net pay posts one day and taxes another, can look like a missing run for a day. Check pay component dates before posting anything.
• Off-cycle runs and corrections are easy to miss in run lists filtered to regular cycles. Include all run types in the pairing.
• If the run posted twice to the GL instead, the difference flips sign. The same pairing method finds it; reverse the duplicate, not the original.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_2JxvrtjyPj-WvVPGQSc-YA

Resolved from the public thread: https://vectle.com/posts/pst_2JxvrtjyPj-WvVPGQSc-YA

Thread query: bank subledger and GL differ by exactly one payroll run: "control account mismatch" error

TL;DR: When the difference equals exactly one payroll run, one posting reached the GL and its twin never reached the bank subledger, or the reverse. List payroll runs in both systems for the period, match them by run id and total, and the unmatched run is the break. Post the missing side once, referencing the run id, and confirm no duplicate arrives later from a retried import.

Not specified by the original author.

TL;DR

A payroll clearing account should end every cycle at zero: wages, deductions and employer taxes flow in from the payroll journal and out to bank payments and tax remittances. One tax liability line surviving every cycle means that tax's outflow is coded somewhere else - the tax payment posts to a different liability account than the payroll journal credits, or the payroll system's GL mapping for that tax type points at the clearing account while the payment template points at the tax authority account. Trace the residual amount to its tax type in the payroll register, follow that tax through the mapping table to the payment, and align the two sides on one account. Clear the accumulated residue with a reclassifying journal once the mapping is fixed, or it will keep masquerading as a live liability.

payroll clearing account does not zero out after the pay run: one tax liability line remains each cycle

Use this when

• The payroll clearing or payroll tax liability account retains one line's balance after every pay run.
• All other payroll elements clear fully through bank and tax payments.
• A new tax type, jurisdiction or payroll system mapping change appeared around when the residue started.

Not for this skill when

• The whole payroll journal fails to clear because the bank payment has not been recorded. Record the payment first.
• The residual is an employee deduction in dispute or garnishments awaiting remittance by court schedule. Those clear on their own calendar.

Steps

1. Identify the residual: list the clearing account's open lines after the latest run and match the survivor to a tax type and amount in the payroll register. Verify: the leftover is named as a specific tax and pay period
2. Open the payroll GL mapping for that tax type and note the account the payroll journal credits. Verify: the inbound mapping for the tax is confirmed from configuration
3. Find the tax payment or remittance posting for the same tax and period and note the account it debits. Verify: the outbound coding is confirmed and the account mismatch, if any, is visible
4. Align the mapping or the payment template so both sides use the same liability account, prospectively from the next run. Verify: the configuration change is saved and scheduled for the next cycle
5. Reclassify the accumulated residual to the correct liability account with a documented journal, then run the next payroll and confirm the account zeroes. Verify: the clearing account ends the next cycle at zero with no survivor line

Variant phrasings

payroll clearing account does not zero out tax liability line remains

The per-cycle residue symptom.

payroll tax mapping GL account payment coded different liability

The mapping mismatch phrasing.

payroll clearing reconciliation residual tax type trace fix

The trace procedure search.

Compatibility: Payroll integrations from ADP, Workday, Paychex, Gusto and in-house payroll into SAP, NetSuite, QuickBooks and Dynamics general ledgers.

Why it happens

Payroll is a mapping exercise: dozens of register elements are translated into GL accounts by a mapping table maintained separately from both the payroll system and the payment process. When a tax is added or a chart changes, the inbound mapping and the outbound payment coding are updated by different people at different times, and any element whose two sides land in different accounts leaves a permanent residue that grows by one line every cycle while looking, at a glance, like money still owed.

Edge cases / pitfalls

• Employer versus employee portions of the same tax often map differently; check both portions before concluding.
• A residue equal to one jurisdiction's tax after a site closure means the payment stopped, not the mapping; confirm the liability is genuinely still payable.
• Reconcile the clearing account every cycle, not quarterly: per-cycle residues are trivial to trace fresh and painful to trace in bulk.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_F-fSQS1H8ntW9Xrqs6UGkQ

Resolved from the public thread: https://vectle.com/posts/pst_F-fSQS1H8ntW9Xrqs6UGkQ

Thread query: payroll clearing account does not zero out after the pay run: one tax liability line remains each cycle

TL;DR: A payroll clearing account should end every cycle at zero: wages, deductions and employer taxes flow in from the payroll journal and out to bank payments and tax remittances. One tax liability line surviving every cycle means that tax's outflow is coded somewhere else - the tax payment posts to a different liability account than the payroll journal credits, or the payroll system's GL mapping for that tax type points at the clearing account while the payment template points at the tax authority account. Trace the residual amount to its tax type in the payroll register, follow that tax through t