TEAM Comunicaciones recibía mensualmente cerca de 7.500 comprobantes de pago a través de WhatsApp. Capturas de pantalla de transferencias, fotografías de recibos, imágenes de distintos bancos y formatos: información financiera valida, pero llegando por un canal que no fue diseñado para operar como sistema de recaudo.
The management process was completely manual. A team of people received each image, read the receipt, extracted the relevant data, checked if it had already been registered before, and cross-referenced it against the bank statements to verify that the money had indeed entered the bank before proceeding to the accounting record of portfolio credit
.
The process was logically sound, but unsustainable at scale.
As the business grew, the volume of documents grew with it. The team dedicated a significant portion of their time to a task that, in essence, was interpreting images and comparing numbers. A repetitive job, high volume, with a low margin of error tolerated, and that did not generate value by itself: it only enabled the recording of a data point that had already occurred in the bank.
The problem was clearly not the team's capability; on the contrary, the team was doing a job that a machine can do better, faster, and with greater consistency.
The diagnosis: Three frictions that shaped the solution
Before designing any solution, it was necessary to understand precisely where the real friction points of the process were. Three structural problems emerged clearly:
• Manual interpretation of unstructured documents: receipts arrived in heterogeneous formats, from multiple banks, with different layouts. There was no standard. Each image required individual reading to extract amount, date, entity, reference number, and destination account.
• Absence of duplicate control: the same receipt could arrive more than once, sent from different devices or at different times. Without an automatic detection mechanism, the risk of recording the same payment twice was constant and depended solely on the memory and attention of the operator.
• Manual validation against bank statements: the critical step of the process was to verify that the money described in the receipt had indeed been deposited in the bank. This cross-check was done manually, comparing the receipt with the preloaded statements. A slow process, prone to error, and which delayed the accounting record of portfolio credits.
Each of these frictions could be resolved independently. But the real value was in solving them together, within a single and coherent flow that connected them from start to finish.
The solution: an AI-powered integrated workflow, control by design, and human judgment where it matters
The architecture of the solution started from a design principle that we consistently apply in AI automation projects: not to design only for the cases that the system can resolve well, but to explicitly design for the cases it cannot resolve with confidence.
The flow works as follows:
• The client sends the payment receipt via WhatsApp. The system receives it automatically, without team intervention.
• An AI model analyzes the image and extracts the relevant data: amount, date, banking entity, reference number, and destination account. This occurs regardless of the format, the bank, or the quality of the image, within the defined confidence ranges.
• The system executes the duplicate validation: it compares the processed receipt against the historical records and detects if that payment has already been received previously, through any channel.
• If it passes the duplicate validation, the receipt is cross-checked against the bank statements preloaded in the system. The purpose of this cross-check is to verify that the value and reference of the receipt match a real transaction recorded by the bank, confirming that the collection actually occurred before enabling the accounting record of portfolio credit.
• If the cross-check is successful, the system generates the record ready for accounting. If there is no match, the case is escalated to the team for manual review with all available information.
So far, the description of the ideal flow. But the design of this solution does not end with the ideal flow.
The 18% AI doesn’t process: designing human oversight
This is perhaps the most important lesson from this project, and the one that is most often overlooked when discussing AI implementations: no model is perfect, and pretending that it is, is the shortest path to a solution that fails silently.
In the case of TEAM Comunicaciones, the system autonomously and reliably processes 82% of the receipts it receives. The remaining 18% is not an error: it is the percentage that the model identifies as outside its confidence range and automatically escalates to the human team for review.
That 18% includes receipts with low image quality, unusual formats, ambiguous references, or values that do not clearly match any transaction in the statements. Cases that require human judgment, not because the technology has failed, but because those cases are designed to reach the human.
The difference between solid automation and fragile automation lies in how well the control over what it does not resolve is designed.
This control design has practical implications that go beyond operation:
• The team does not review the 7,500 supports: it reviews the 1,350 that the system could not process with certainty. Their work focuses where their judgment truly adds value.
• Traceability is complete: each receipt has a clear status, a documented reason if it was escalated, and a defined responsible party if it required human intervention.
• The system learns from corrections: the cases that the team resolves manually feed back into the model to progressively reduce that 18% over time.
• Operational risk is controlled: no receipt remains in an undefined state. It was either processed automatically with confidence, or it is under active review by a human.
The impact on operations: numbers and role changes
The most visible result is quantitative. Of the 7,500 monthly supports processed manually, 82% is now managed automatically: interpretation, duplicate validation, cross-referencing against statements, and generating the record for accounting. Without human intervention in those cases.
But the most relevant impact is the change in the team's role.
Previously, the finance team was a data operator: it received images, read receipts, compared numbers, and recorded manually. A job of high volume, low variability, and little room for analysis.
Today, the finance team is a process supervisor and an exception manager: it handles the complex cases that the system escalates, validates business rules when new situations arise, and has complete visibility over the status of each receipt in real time.
Automation did not reduce the team. It changed their work, allowed them to add more value in other processes, and leveraged the company's growth.
The lesson that applies beyond this case
TEAM Communications had a flow and scale problem, and the solution was to design the correct flow first, build the technology to support it, and define from the beginning how to manage the cases that the technology cannot resolve on its own.
That third element, the design of human control, is the one that is most frequently omitted in automation projects. And it is precisely what determines whether a solution is solid in production or if it creates a new source of problems that no one anticipated.
A well-designed AI implementation does not require automating everything; it actually only needs to know precisely what to automate, what to scale, and how to manage the boundary between the two.
At EmasT, we design automation solutions that work in production, not just in demos. If you have high-volume processes involving unstructured data, let’s talk.