Source vs posted
Compare what the payroll file or remittance said with what posted to the ledger, by plan, transaction type, and date.
How a TPA operations team reconciles source totals to posted ledger activity, manages ACH settlement batches and clearing files, clears out-of-balance items, and records adjustments with a full audit trail.
In a pooled trust arrangement, money for many participants, and often many plans, sits in a shared account. The custodian sees one balance. The recordkeeping ledger is what says which plan and which participant each dollar belongs to. If the ledger and the money drift apart, participant statements, distributions, and the plan's financial reporting all inherit the error.
Reconciliation is the routine that keeps them together. It answers three questions on a regular schedule: did everything the source says should arrive actually post, did everything that posted actually settle, and is every remaining difference explained and owned by someone? Done daily or per batch, reconciliation is short and boring. Left for month end, it turns into an investigation.
Compare what the payroll file or remittance said with what posted to the ledger, by plan, transaction type, and date.
Confirm posted transactions are grouped into ACH clearing files and that each file settled for the expected amount.
Any remaining variance becomes a flagged item with an owner, a reason, and a documented resolution.
Decide what you are reconciling (one plan, one batch, or the whole pooled account) and the cutoff time. Transactions that arrive after the cutoff belong to the next cycle. A clear cutoff stops timing differences from looking like errors.
Collect the totals that should have posted: validated payroll batch totals, employer contribution amounts, loan repayments, distribution and rollover instructions, and fee deductions. Each of these is the independent figure you will test the ledger against.
Filter ledger activity by plan, transaction type, and date range, and compare it to the source totals. A payroll batch of a given total should produce deferral, match, and loan repayment transactions that add back to that total. Differences go on a list immediately rather than being netted against each other.
Transactions that move money are batched into ACH clearing files. Check for unbatched transactions that are still waiting for a clearing file, and make sure nothing has been batched twice. A pending settlement total that does not match the sum of its transactions is a stop sign.
When the funds clear, mark the settlement batch as settled and compare the amount to the bank or custodian confirmation. Only then should the underlying transactions move from pending to reconciled.
Anything that still does not match is flagged as a discrepancy and moved into the exception tracking workflow, linked to the plan, sponsor, participant, payroll batch, and ledger transaction involved.
Correct errors with a new adjustment transaction that states the amount, allocation, and reason. Do not overwrite or delete the original entry. The ledger should always be able to show what was posted, what was wrong, and how it was fixed.
| Item | Likely cause | How to handle it |
|---|---|---|
| Funding received differs from batch total | Sponsor funded from an older file, or a partial ACH | Confirm which file was funded; post only what is supported and flag the variance with the sponsor. |
| Custodian confirmation differs from ledger | Rounding, timing, or a missed transaction | Trace by transaction ID and date. If a correction is needed, record an adjustment with the reason. |
| Unbatched transactions | Posted after the clearing file was built | Include them in the next clearing file. Watch for items that stay unbatched across cycles. |
| Large single employer contribution | Annual profit sharing or cash balance funding | Confirm the amount against the contribution calculation before it settles. |
| Plan-level vs participant-level mismatch | Amount posted to the plan but never allocated | Allocate to participants, or document why it is held at plan level, such as a forfeiture or fee account. |
Never offset one unexplained difference against another. Two errors that happen to net to zero are still two errors, and they will resurface separately.
Clean reconciliation records also support the plan's annual reporting and any audit of the plan's financial statements. If a plan sponsor or auditor asks how a balance was derived, the answer should be a filtered ledger export, not a spreadsheet rebuilt from memory.
The Recordkeeping & Ledger area in the pilot build covers the pooled trust ledger, ACH settlement, and exception resolution across all plans. All records are synthetic demo data.
There are no live custodian or bank connections in the pilot build. See the screens on the pilot build tour.
It is the routine of confirming that the recordkeeping ledger, which assigns each dollar to a plan and participant, agrees with the source instructions and with the money that actually settled in the shared trust account. Any difference is flagged, investigated, and resolved with a documented adjustment.
Many teams reconcile per batch or daily, with a fuller review at month end. The right frequency depends on transaction volume and the service agreement, but shorter cycles keep differences small and easier to trace.
It is a posted transaction that has not yet been included in an ACH clearing file. Unbatched items are normal right after posting, but any that stay unbatched across several cycles should be investigated.
No. Record a separate adjustment transaction with the amount, allocation, and reason, and leave the original entry in place. That keeps the ledger traceable from the original posting through the correction.
This guide is general educational information about retirement plan operations, not legal, tax, or investment advice. Confirm current IRS and DOL rules and the terms of each plan document before acting.
We will show source totals, clearing files, settlement, and a discrepancy moving through resolution, then talk about what a pilot would need to prove for your plans.