For a long time, the monthly close at a small Catalan business advisory firm demanded an amount of attention that seemed inevitable. Before approving the billing run, the team had to review clients, categories, items and relationships that might have been recorded in different ways. The same client could appear more than once. Two categories with different names could mean almost the same thing. A small inconsistency, barely visible when introduced, would reappear weeks later at the most delicate moment.
The team had learnt to spot many of those problems. That was precisely why the process kept working. People knew the exceptions, remembered which names were equivalent and knew where to look when an invoice did not quite add up. But that capability came at a cost: every month-end, part of the organisation became a manual quality-control system.
In a business advisory firm—an enterprise built on rigour and trust—an invoice is not a secondary procedure. It is concrete evidence that the organisation knows what service it provided, to whom, under which criteria and for what amount.
When Monreal & Meadow began working with the firm, we did not frame the problem as simple invoice automation. The invoice was the final document in a much longer journey. To reduce its errors, we had to understand how the information that eventually reached it had been created.
The monthly close had become a late quality-control exercise
A final review may be a reasonable measure. The problem appears when it stops serving to check exceptions and becomes the only way to trust the set.
At this firm, the monthly close concentrated the accumulated effect of many small decisions. Creating a customer, assigning a category, linking a service, updating a condition or reusing a record looked like a set of independent actions. Yet they all converged in billing. If one was completed with incomplete information or a different criterion, the error travelled silently to month-end.
The natural response was to check more carefully. The more important accuracy was, the more people and time were spent checking it. That protected the result, but it also hid the source of the problem: the system did not distinguish clearly enough which data was valid, which entities were the same, and which combinations needed a check before continuing.
The review had become a compensation. The organisation added human criteria at the end because the architecture had not incorporated it at the time the decision was made.
The invoice error arose much earlier
A duplicate customer is not just a repeated row. It can split your history, associate services with different identities, make verification more difficult, and cause two people to reach different conclusions using data that appears correct.
Entity resolution research calls this problem record linkage, deduplication or entity resolution: recognizing when multiple records actually refer to the same person, company or object and constructing a canonical representation. The review published by Olivier Binette and Rebecca Steorts explains that systematically and accurately cleaning and integrating records is a precondition for being able to confidently use information from different sources: Science Advances — “(Almost) all of entity resolution”.
Duplicate categories produced a similar effect. The problem was not that two labels were spelled differently, but that the organisation was losing a common language to describe its work. When each person had to interpret whether two categories were equivalent, consistency depended on memory, experience, and local context.
That is why we did not begin by asking how to review invoices faster. We began by asking what path each piece of information had taken, where it was created, what decision it represented, what options the person had at that moment and why the system allowed two incompatible answers to appear equally valid.
We started by observing decisions, not by installing a tool
Monreal & Meadow's way of working is based on a simple idea: an organisation cannot be explained solely through the processes it has documented. You have to get into the real work and see how normal situations are resolved, what happens when information is missing, and who you turn to when an exception appears.
We worked alongside leadership and front-line managers. We followed the flow of information through to the invoice, identified where ambiguity arose and reconstructed the criteria the team was already using to correct it. We did not arrive with a closed tool designed to impose a new way of working. We built from the decisions the organisation needed to make and the knowledge already present within it.
This distinction matters. If a solution merely digitises the documented process, it can preserve every inconsistency behind a more modern interface. If it tries to replace people's judgement without understanding it, the team is forced to work around the tool. In both cases, a second informal operation emerges: the official one inside the system and the real one in conversations, notes and later reviews.
Our work consisted of bringing both together. We made explicit the rules that could be shared, outlined the decisions that needed context, and designed an architecture where information could retain its meaning from one step to the next.
An architecture that makes it easier to do the right thing
Data quality is not achieved by cleaning a database once. It requires decisions about what each entity represents, which attributes identify it, which relationships are admissible and what should happen when the information does not support a sufficiently confident answer.
The ISO/IEC 25012 standard defines a general model for establishing data quality requirements, measurements and evaluations, including production, acquisition and integration processes. The useful idea here is that quality should be specified in relation to the use to which the information will be put; It cannot be evaluated only when the final document is already generated: ISO/IEC 25012 — Data quality model.
In this case, that meant working on an architecture capable of promoting a coherent representation of customers and categories, validating relevant combinations and making an anomaly visible close to the moment where it occurred. The goal was not to fill every action with permissions and checks, but rather to reduce ambiguous possibilities and provide context when a decision actually changed.
Good architecture does not eliminate every possibility of error. It makes the right option recognisable, a probable duplicate detectable and doubtful situations unable to continue silently towards the invoice. Control therefore stops being a mass inspection at the end and becomes distributed throughout the flow.
Intelligence helps when it knows not to decide
Not all duplicates are alike. Two companies may share words in their names without being the same entity. A customer may change its name, use an abbreviation or appear with incomplete data. An overly simple rule can miss a duplicate; overly aggressive automation can merge records that should remain separate.
That's where we build smart tools and supporting technologies. Their role was not to declare that all cases were resolved, but to compare signals, detect inconsistencies, propose relationships, and direct the team's attention to exceptions that needed professional judgement.
The distinction between automating an answer and automating the preparation of a decision is fundamental. In clear cases, the system can prevent or resolve repetitive work. In uncertain cases, it should preserve doubt, gather context and allow a person to decide without reconstructing the entire history from scratch.
The result is more proportionate control. The team no longer gives every invoice the same attention and can focus on genuine deviations. Technology does not replace professional judgement; it prevents that judgement being wasted on repeatedly checking situations the system can already keep consistent.
Accuracy does not come from reviewing all invoices. It comes from knowing which decisions are already reliable and which still need attention.
The tool had to adapt to the firm, not the other way round
A technically correct architecture can fail if it forces people to abandon the knowledge that makes the business run. That is why the implementation was not treated as a software delivery, but as a collaboration with those who made the decisions every day.
The work sessions with management and operational managers served to compare rules, understand exceptions and adjust the operation of the tools. Each prototype made it possible to check not only whether the technology worked, but also whether the information appeared at the right time, whether an alert was understandable, and whether the effort required was related to the risk it avoided.
This hands-on support also changed the ownership of the solution. The firm did not receive a black box that only Monreal & Meadow could interpret. Its team helped build the criteria, understood which decisions were automated and retained the ability to recognise when the system needed review.
ISO 8000-61 treats data quality as a set of processes that can be improved and evaluated, while ISO 8000-150 focuses on the functions and responsibilities necessary to manage it. Both reinforce an idea that the project made tangible: quality does not belong exclusively to the software nor can it depend indefinitely on a person who reviews at the end. It must be part of how the organisation works and governs its information: ISO 8000-61 — Data quality management and ISO 8000-150 — Roles and responsibilities.
Accuracy is not about checking more, but about needing to check less
With the new architecture and the tools built around it, the firm brought billing errors close to zero. The monthly close became smoother and the team could trust that much of the control had already happened before the invoice was generated.
The result did not come from a single rule or a model capable of guessing everything. It came from connecting data architecture, operational decisions, automation and adoption. Monreal & Meadow brought the ability to work across that whole space: enter the operation, find where the problem began, translate the client's criteria into a technical structure and support the team until it became part of how they worked.
That also changes the meaning of efficiency. Saving review time matters, but the most profound improvement is regaining trust. When the organisation stops wondering each month if all the data is right, it can focus its attention on serving better, resolving complex cases, and improving the service it provides to its customers.
An accurate invoice is the visible result. Beneath it is something more valuable: a system that makes it easier to work well.
You do not fix an invoice at month-end. You begin looking after it with the first decision that will eventually reach it.