← Blog Automating a process
PSE payment reconciliation: how to automate it without losing control
PSE payment reconciliation is automated by matching gateway, invoices, ERP, and bank data with auditable rules. AI can help with secondary tasks, but it shouldn't decide whether a payment reconciles.
Key takeaways
- The source of truth isn't one system: match gateway, PSE, ERP, and the bank statement before closing the accounting day.
- Matching should be deterministic: use CUS, reference, amount, date, invoice, and status before free text.
- Pending items don't get forced: a pending, rejected, errored, or returned PSE payment needs a queue with an owner and a reason.
- AI almost never decides reconciliation: it helps normalize descriptions, read attachments, or classify exceptions. It shouldn't approve collections.
What does PSE payment reconciliation mean in a company?
PSE payment reconciliation is the match between what the customer tried to pay, what the gateway reported, what the bank credited, and what the ERP expects to collect. In Colombia, PSE allows online payments by debiting funds from savings accounts, checking accounts, or electronic deposits, as described by ACH Colombia.
The problem starts when each source speaks differently. The gateway may say “approved.” The ERP may still show an open invoice. The bank may credit the money the next day. Accounting may see fees or withholdings separately. If the team matches all that in Excel, closing becomes slow and fragile.
PSE has detailed reconciliation files. In the business help center, the “Archivos Conciliación” option lets companies choose structures such as Asobancaria 1998, Asobancaria 2001, Andesco, and PSE. It also has a checkbox to generate files automatically, according to PSE business help. In that same documentation, “No. de Operación” is the CUS, the unique tracking code that PSE assigns to each transaction.
The goal isn't for the system to guess. The goal is to reconcile what has enough evidence and send only unusual cases to review. Good automation reduces manual work without removing accounting traceability.
What data do you need to automate PSE payment reconciliation?
Before building rules, define which source wins in each case. This table is a starting map for finance and technical teams.
| Source | Data worth storing | What it's used for |
|---|---|---|
| Gateway | ID, reference, status, amount, dates | Know what the payment method reported. |
| PSE | CUS, authorization, bank, status | Match the transaction against the collection. |
| ERP or receivables | Invoice, customer, balance, due date | Apply the payment to the right document. |
| Bank | Credit, date, account, description | Confirm that the money came in. |
| Accounting | Fee, tax, accounting account | Record differences and costs. |
| Audit log | Rule, user, change, time | Audit what happened with each payment. |
If the order or invoice reference is missing, reconciliation is weak. In that case, fix the source instead of compensating with AI.
How do you automate PSE payment reconciliation step by step?
- Define the primary identifier. The best identifier is usually the merchant’s own reference: invoice, order, obligation, or receipt. Then match it with CUS, authorization, gateway ID, amount, and date. If you sell through ecommerce, the reference should exist before payment and travel intact to the ERP.
- Receive events and download reports. Webhooks help update statuses fast, but they don't replace the daily close. For example, Wompi documents events that notify transaction changes, such as approved or rejected, and retries when the merchant doesn't return HTTP 200, in its Colombia events documentation. You should also download daily reports to catch missed events.
- Normalize statuses. Each gateway uses different names. Create an internal table with statuses such as approved, pending, rejected, error, voided, and returned. That table should say whether the payment can be applied, should wait, or needs review.
- Run matching rules. Start with exact rules: same reference, same amount, and approved status. Then accept controlled variations, such as nearby dates or separate fees. Rules need priority. An exact rule wins over a text match.
- Create an exception queue. Anything that doesn't close goes to a queue. Each exception needs a reason: different amount, missing invoice, duplicate payment, bank credit missing, reversal, refund, or incomplete reference. That queue needs an owner and a deadline.
- Measure before closing. Measure the automatic reconciliation rate, exceptions by reason, payments without bank credit, payments without invoice, and reprocessing. These metrics show whether the system improved or only replaced Excel with another screen. At Quarl, we use the same standard in AI automation: measure first, then adjust.
How do you match gateway, bank, and ERP without silent errors?
The safest rule is to separate three moments: authorization, settlement, and accounting application. An approved payment in the gateway doesn't always mean accounting can close it. First, confirm the payment status. Then validate the bank credit. Last, apply the collection to the invoice or receivable.
Gateway reports are still needed. Mercado Pago Colombia says the “All transactions” report lets you check each transaction's details, generate it from the dashboard or API, schedule it daily, weekly, or monthly, and download it as .csv or .xlsx, according to its report generation documentation.
In practice, the system should run three daily matches. First, gateway against ERP: does the payment belong to a real invoice? Second, gateway against bank: did the expected money come in? Third, ERP against accounting: was the invoice applied to the right account?
When there are differences, don't overwrite the original data. Store the received data, the normalized data, and the decision made. That log helps when audit asks about a specific payment or when receivables needs to explain why an invoice is still open.
If the process includes reversals or refunds, treat them as their own events, not as simple negative payments. In Colombia, Decree 587 of 2016 regulates payment reversals in ecommerce, including PSE. The legal summary says the consumer must file the complaint within five business days in the listed cases. This isn't legal advice and should be reviewed with legal counsel in the SISJUR summary of Decree 587 of 2016.
Illustrative example: receivables with PSE payments and open invoices
This example is illustrative. It's not a client. It helps ground the flow decisions.
Input
Invoices and payments arrive through different paths
A services company bills monthly invoices. The customer pays by PSE through a link. The gateway sends the status, PSE provides the reconciliation file, the bank shows the credit, and the ERP keeps the invoice open.
System
Rules match before applying
The system takes the invoice reference, CUS, amount, date, and status. If everything matches, it marks the payment as reconciled and sends the application to the ERP. If the bank credit is missing, it leaves the payment on hold.
AI doesn't approve the payment. It can only help classify exceptions from text.
Operating result
The team reviews exceptions, not repeated rows
Receivables sees a queue with duplicate payments, mistyped references, partial amounts, and refunds. Accounting sees which rule applied each payment and can export closing support.
If you need to connect gateway, ERP, and bank, it's usually an <a href="/en/integrations-and-apis">integrations and APIs</a> job more than an AI model.
When should you use an existing tool, automation, or custom development?
| Option | When it fits | Typical limit |
|---|---|---|
| What the gateway includes | Low payment volume and one channel | Doesn't apply your receivables rules. |
| Automation with reports | Medium volume and clean data | Depends on files and schedules. |
| API integration | Near real-time statuses | Needs failure handling and retries. |
| Custom development | Several banks, ERPs, and accounting rules | Needs design, testing, and support. |
Cost and timeline depend on connected sources, reference quality, accounting rules, ERP permissions, and tests with historical data. If the current process is already broken, clean up the data first.
What we do
Frequently asked questions
How is PSE payment reconciliation done?
You match payment data with the invoice, gateway report, PSE information, and bank credit. If reference, amount, status, and bank match, the system can apply the payment. If data is missing or different, the case should go to an exception queue with a reason and an owner.
What is the PSE CUS and how is it used in reconciliation?
The CUS is the unique tracking code that PSE assigns to a transaction. It helps track the operation within the payment flow. In reconciliation, it helps connect what PSE reports with what the gateway shows and the merchant’s support records. It doesn't replace the invoice or order reference.
Is a webhook enough to reconcile payments, or do I need daily reports?
A webhook helps you learn about status changes quickly, such as approved, rejected, or error. Even so, daily reports are useful because an event can be missed, arrive late, or fail during a temporary outage. Good reconciliation combines events for daily operations and reports for closing and audit.
What happens with pending, rejected, or errored PSE payments?
Pending payments should stay on hold until they have a final status or meet an expiration rule. Rejected and errored payments shouldn't be applied to receivables. If the customer insists they paid, the team reviews CUS, bank, gateway, and support records before changing the accounting status.
When does AI make sense in payment reconciliation?
AI makes sense for tasks where data arrives messy, such as reading receipts, classifying emails, or suggesting exception reasons. It shouldn't decide that a payment reconciles if bank evidence, reference, or final status is missing. In payments, traceable rules give better control than a prediction.
Written by
Quarl engineering team
We are an AI engineering team in Medellín. We build and run systems that reach production — automations, assistants and agents — and for three years we ran an assistant for two million users across ten countries.
See how we work →Want to apply this in your company?
In fifteen minutes we tell you whether it is worth it, free and with no pitch. The proposal arrives within 48 hours.