A payment screenshot versus a signed CEP: what can your reconciliation job accept?

The problem: an image is not the original record

A screenshot of a banking app shows an amount, a date and perhaps a tracking key. It can be cropped, edited or simply belong to a different transfer. A CEP (Comprobante Electrónico de Pago) is the original electronic receipt for an existing SPEI payment, and it can carry a signature and data that bind it to one operation. The reader's decision is narrow: what evidence may your reconciliation job accept before it marks an invoice as paid, and what must it leave open? A screenshot can be useful as a hint to start a lookup, but it should not be the thing your job accepts.

What the product checks, and what it does not

The mx-cep product retrieves the CEP for an authorized existing payment and inspects its signature and transaction binding. Inputs are the operation date, tracking key, sending and receiving institution codes, account, amount and an authorization reference. Output reports task status, original-evidence availability, signature status and exact transaction binding. Boundaries matter: it does not initiate a transfer, and it does not prove present account control, identity or that a payout is safe. Source access restrictions can delay a task, so a result may stay pending for a while. Merchant execution requires current capabilities, authorization and an accepted quote; documentation is not evidence of a live check.

Hypothetical scenario and the expected fixture output

Hypothetical: an invoice for a synthetic merchant shows an inbound transfer and a customer screenshot. The job submits the operation date, tracking key, both institution codes, account, amount and authorization reference. The synthetic contract example returns exactly: status pending, original_available false, signature_status not_checked, transaction_binding not_checked, verified false. No live provider request is performed by this example. The correct reading is that nothing has been established yet: the original is not available, the signature was not checked and the CEP was not matched to the invoice. The invoice stays open, labeled as awaiting evidence, not as paid and not as fraudulent.

Proposed acceptance rule for your application

This is proposed application design, not implemented product behavior. Accept a payment as evidenced only when verified is true, original_available is true, and both signature_status and transaction_binding report a successful check that you have mapped explicitly. Compare the bound transaction against your own expected amount, account, institutions and date rather than trusting a single flag. Treat pending, unavailable, not_checked and any unknown value as inconclusive. Keep the decision to ship goods or release funds as a separate business rule owned by your code; a matching CEP says a payment happened, not that the counterparty is who they claim or that a payout to them is safe.

Failure handling without duplicates

When a task is pending, store its identifier with the invoice and a deadline, then use get to read status or recover to resume it, instead of submitting a second request for the same payment. Delays from source access restrictions are expected; do not convert them into rejection. If the deadline passes with no conclusion, route the invoice to manual review with the reason recorded. If binding fails, flag a mismatch for a person to investigate; it may be a typo in inputs as well as a wrong transfer. Never let a timeout, an error or a screenshot fill the gap by default.

Acceptance checklist

Before relying on this in reconciliation, confirm: the synthetic output above maps to awaiting evidence, not paid; verified false never marks an invoice paid; pending and unavailable stay inconclusive; all six inputs and the authorization reference are recorded per request; repeated runs reuse the existing task instead of creating duplicates; mismatches go to review; release decisions remain separate from payment evidence; and the team understands the fixture is a synthetic contract example, not live acceptance, with no live capabilities assumed until your merchant authorization and accepted quote are in place.

Inspect this product

https://gridzen.ai/tools/mx-cep/ · Inspect the documented input, output and boundary. This command lists the product without executing a live request.

gridzen tools --product mx-cep

Sources and scope

https://gridzen.ai/tools/mx-cep/ https://gridzen.ai/guides/current-capabilities/ Based on the checked source snapshot and local fixture; proposed application rules are design advice, not proven production behavior. Written with AI assistance and reviewed independently.