Teams that financially audit KYC verification applications often inherit a comfort: if identity evidence exists, the customer “is onboarded.” Finance does not share that comfort. Finance wants to know whether the event that legal and AML treat as complete created the cash movement, deferred income, or blocked payout the product contract described.
A reconciliation in this setting is a join, not a vibe. Left side: a defined KYC event (“verification complete,” “manual override accepted,” “screening cleared”). Right side: a defined ledger event (fee, reserve, freeze, first funded credit). Key: a customer or application identifier that both systems actually share. If the identifier is a display name, stop. You do not have a join.
Three unmatched patterns we see
First, completeness the other way: money moved and the KYC application still shows pending. That is cut-off and, in some books, a control that failed to prevent a funded state. Second, KYC complete and no fee where a fee was contracted — existence of income. Third, a freeze flag in the application and an outgoing payment that still settled. That last one is the pattern people remember in committee, which is why it should not be the only pattern you tested.
Do not “explain away” unmatched items in the worksheet footer with “timing.” Timing is a hypothesis. Write the window you used (say, T+1 UK working day) and keep the item unmatched until someone shows a booking inside that window or a documented waiver.
Evidence that looks stronger than it is
A screenshot of a green banner in the KYC UI is weak evidence of a financial event. A vendor callback ID plus a ledger journal ID is stronger. An operator comment that “customer is fine” is not evidence of either. In GB files we have seen all three stapled together as if they were equivalent. They are not.
Module 04 of the Audit Lab uses a pack where 41 synthetic items fail the fee join. Trainees who reconcile only the happy path never meet them. If you want the method without a seat, the public sketch lives on the Control ledger page.
What to write when you cannot join
Sometimes the application and the ledger were never designed to share a key. That is a finding about the design of the control environment, not a reason to skip the test. Say you could not join. Propose a compensating sample (manual tickets, for example) with a smaller population and a louder limitation. Pretending the screenshot is the join is how financial audits of KYC applications lose the plot.