---
title: "Comment by Azhar Abbas on \"Would Your Payments Code Pass an Audit?\n5 Tests You Can Run Today\" | Hashnode"
description: "The two-way reconciliation is the key part here. One useful addition is to test the processor report for duplicate IDs before joining it: a duplicate on either"
url: "https://hashnode.com/posts/would-your-payments-code-pass-an-audit-5-tests-you-can-run-today/6af5ed8b537a5b51108f83e3/comment/6af6bb046f8563d7a013f0e9"
---

[Discussion](https://hashnode.com/posts/would-your-payments-code-pass-an-audit-5-tests-you-can-run-today/6af5ed8b537a5b51108f83e3)

Comment [Would Your Payments Code Pass an Audit? 5 Tests You Can Run Today](https://hashnode.com/posts/would-your-payments-code-pass-an-audit-5-tests-you-can-run-today/6af5ed8b537a5b51108f83e3)

[Azhar Abbas](https://hashnode.com/@azharabbas)

[14h ago](https://hashnode.com/posts/would-your-payments-code-pass-an-audit-5-tests-you-can-run-today/6af5ed8b537a5b51108f83e3/comment/6af6bb046f8563d7a013f0e9)

The two-way reconciliation is the key part here. One useful addition is to test the processor report for duplicate IDs before joining it: a duplicate on either side can multiply rows and make the amount comparison misleading. I would also separate pending settlements from genuine exceptions using an explicit cutoff, so a normal settlement delay does not hide a growing backlog.