A batch can contain repeated accounts and distinct payments. The correct deduplication key depends on the question you need to answer.
Choose transaction or account coverage
For invoice reconciliation, two payments to the same CLABE are still separate operations. Deduplicate exact transaction requests using the date, tracking key, amount, institutions and account. Never mark every payment verified because one payment to that account has a CEP.
For an authorized historical account-name study, selecting one suitable payment per account may reduce retrieval work. Label that outcome account coverage. Keep the remaining transaction index and explicitly record which transactions were not checked.
Handle a batch as durable individual tasks
Preserve identifiers as text when exporting spreadsheets. Scientific notation or rounding can corrupt a CLABE or tracking key. Map bank codes before queueing. Submit bounded work, save each task ID, and poll existing tasks instead of recreating the batch after an interruption.
Receiving many tasks at once does not make the official source faster. A shared sending budget, bounded retries and visible queue states protect both the application and the source.
Keep caches scoped
An exact, previously verified operation can provide reusable evidence within the same permitted tenant and retention policy. Account-level history is dated evidence, not a fresh check. Do not merge one merchant’s beneficiary records into a public name lookup service. Report indexed rows, originals, valid signatures, bound transactions and distinct-account coverage separately.
Official CEP information · GridZen CEP Verify
Limited real trial: verified business email, 10 lifetime attempts per domain, 50 service-wide per day. Paid checkout is disabled. Upstream access and CEP availability can delay results. No new transfer is created.
Written and reviewed by the GridZen team with AI assistance.
Top comments (0)