401(k) plan exception tracking with a trail you can defend.
How TPA teams detect discrepancies, work them through a single exception queue, link each one to the records it affects, and close it with resolution notes that stand up to review.
Exceptions are where plan risk actually lives.
Most transactions in a well-run plan are routine. The risk sits in the small number that are not: a contribution that does not match the census, a custodian confirmation that differs from the ledger, a deposit that arrived late, a participant whose allocation looks wrong. How a TPA finds, assigns, and closes those items says more about the quality of its administration than any clean-path process.
Without a single queue, exceptions scatter across inboxes, spreadsheets, and sticky notes. Nobody can say how many are open, which are getting old, or how the last similar issue was resolved. When the sponsor, a plan auditor, or a regulator asks what happened, the team has to reconstruct the story. Plan exception tracking fixes that by giving every discrepancy one home, one owner, and one written outcome.
A good exception record answers
- What was detected, when, and by which check
- Which plan, sponsor, participant, batch, and transaction are involved
- How large the variance is
- What the suggested fix is, and who decided
- What was done, and why
Signs the current process is failing
- Open items nobody can count without asking around
- Resolutions recorded only in email
- The same issue recurring for the same sponsor
- Items closed with no note of what changed
From detection to closed exception in six steps.
Detect with defined checks
Exceptions should come from defined checks, not from someone happening to notice. Typical sources are payroll validation against the census, comparison of source totals to posted ledger activity, custodian confirmations, deposit timing checks, and annual testing results. Each check should produce an item with a clear description and a detection timestamp.
Route everything to one queue
Send every exception, whatever its source, to a single queue with a unique ID and an open status. One queue makes the workload visible and lets the operations lead see what needs human review each morning.
Link the affected records
Attach the exception to the plan, the plan sponsor, the participant (or mark it as a plan-level item), the payroll batch, and the ledger transaction, along with the transaction amount and variance. Linked records save the reviewer from searching across screens, and they make later reporting possible.
Review the suggested resolution
Where the cause is clear, the check can propose a fix, such as reallocating a contribution or posting an adjustment. A person still reviews it. Where no suggestion exists, the reviewer investigates and documents the corrective action in the notes.
Approve or dismiss, with notes
Two outcomes cover most cases. Approve the resolution when a correction was needed and has been made, which marks the underlying transaction resolved. Dismiss when the item turns out not to be an error, which returns the transaction to its reconciled state. Either way, write resolution notes explaining what was found and what was done.
Age, review, and learn
Review open exceptions by age at least weekly. Anything past your internal threshold gets escalated. Each quarter, look at closed items by type and sponsor; repeated causes usually point to a payroll setup problem or a missing census update that can be fixed at the source.
Typical items in a 401(k) exception queue.
| Exception | Usual source | Typical resolution |
|---|---|---|
| Custodian confirmation differs from ledger | Reconciliation | Trace by transaction; post an adjustment if the ledger is wrong, or dismiss with notes if the difference is timing. |
| Contribution for an unknown participant | Payroll validation | Obtain census data from the sponsor, confirm eligibility, then allocate. |
| Match not following plan formula | Payroll validation | Calculate the correct match, correct the allocation, and ask the sponsor to fix payroll setup. |
| Late deposit of deferrals | Deposit timing check | Escalate to the sponsor and plan fiduciary; correction may involve lost earnings and is handled under current DOL guidance. |
| Limit exceeded | Annual testing | Hand off to the testing workflow for corrective distribution or other approved correction. |
Dismissing an exception is a decision, not a shortcut. A dismissal note should say why the item is not an error, so a reviewer a year from now reaches the same conclusion.
What makes an exception log audit-ready.
Controls
- No exception closes without resolution notes
- Approval of financial corrections by someone other than the preparer, where staffing allows
- A written aging threshold and escalation path
- Exceptions linked to the plan and transaction, not tracked in a separate sheet
- Periodic review of dismissed items
Evidence to retain
- Exception ID, detection time, and source check
- Linked plan, sponsor, participant, batch, and transaction
- Variance amount and suggested resolution
- Final decision, who made it, and the notes
- Any adjustment entry created as a result
Plan sponsors acting as fiduciaries benefit from this record too. A clean exception history is part of showing that the plan is being operated carefully. See our fiduciary reporting overview for how this feeds sponsor-facing reporting.
How the KinetiPlan pilot build supports this.
The pilot build includes an exception resolution center for ledger discrepancies. It runs on synthetic demo data.
- Each discrepancy has an ID, plan, sponsor, detection timestamp, status, variance, and linked ledger transaction.
- A linked records panel shows the plan, plan sponsor with EIN, participant (or plan-level exception), payroll batch, amount variance, ledger transaction, transaction amount, and transaction status.
- A suggested resolution appears when one is on file; otherwise the reviewer is prompted to document the corrective action in the notes.
- Resolution notes, an Approve Resolution action that marks the transaction resolved, and a Dismiss action that returns it to reconciled.
- The operations dashboard shows items needing review, and each plan page shows its count of open discrepancies.
AI-assisted resolution is planned for a later phase only; the pilot build's Ask Kineti AI panel is a preview and calls no AI service. See the screens on the pilot build tour.
Common questions
What is 401(k) plan exception tracking?
It is the process of capturing every discrepancy found during plan operations, such as a contribution that does not match the census or a ledger amount that differs from a custodian confirmation, in one queue, assigning it, and closing it with a documented resolution.
What is the difference between approving and dismissing an exception?
Approving a resolution means a correction was needed and has been made, so the underlying transaction is marked resolved. Dismissing means the item turned out not to be an error, so the transaction returns to its reconciled state. Both should include notes explaining the decision.
How should a TPA age open exceptions?
Use the detection date to measure age, review open items at least weekly, and set a written threshold after which items are escalated to a senior reviewer or the sponsor. Items involving deposit timing or limits may need faster handling because of regulatory deadlines.
Does the KinetiPlan pilot build use AI to resolve exceptions?
No. AI features are planned for a later phase, and the Ask Kineti AI panel is a preview that calls no AI service. In the pilot build, a person reviews every exception and either approves a resolution or dismisses it.
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.
Walk an exception through the pilot build.
We will open a discrepancy, review its linked records, and close it with notes, then discuss which exception types matter most for your book of business.