ARS 2,008millionin cheques collected and never deposited.
This system found them the first time it ran over the ERP of a wholesale distributor: more than ten years old, more than 200 tables. The data had been in the database since day one; what was missing was that anyone could ask.
Cheques collected and not deposited · 2,148 cheques · ARS 2,007,646,935.25See the query
overdue uncollected invoices: ARS 1,528 million, 30.1% of the open balance
Overdue receivables
9
published questions, four on the ERP and five on the collections queue. Outside the catalogue, the system does not answer
Each with its query in plain sight
The system, running on the real case
A wholesale distributor. The ERP is more than ten years old, has more than 200 tables and columns whose names nobody remembers the meaning of. The sales manager would ask how much was lost to bounced cheques and the answer took several queries, manual work, and another department having the time. The expensive part was not the wait: it was that, knowing that, some questions never get asked, and the decision gets made anyway, with whatever number is at hand. The point is that anyone should be able to ask.
Each case is shown twice, with the same real answers computed over that ERP: as it would reach the person asking — the phone is an illustration built with that data — and as the auditor sees it, with the query that computed it. The data is real, anonymised, with amounts scaled by a constant factor.
The ERP
Consistent answers from a complex ERP
That is how the ARS 2,008 million at the top of this page turned up: 2,148 cheques collected and never deposited. Below, the query that found them.
Nobody had written down what “revenue” means in that company, so every dashboard produced a different number, all correctly computed, and every meeting began by arguing over which one counted.
The four ERP questions
How it would reach the person asking
zQuestions to the ERPread-only
What is total revenue?
Total revenue for the period is ARS 39,734,401,800.21, across 15,817 invoices.
Total revenue for the period is ARS 39,734,401,800.21, across 15,817 invoices.
To audit: the query that computed the answer
SELECT ROUND(SUM(total), 2) AS ingresos_totales_pesos,
COUNT(*) AS facturas
FROM facturas
WHERE estado <> :anulada;
Collections
The collections queue, reordered with the missing datum
There are 486 overdue invoices worth ARS 1,528 million and contacting everyone is not viable. Sorted by amount, the queue points first at a client that pays 3.2 days early: no call is required; a reminder is sufficient. Sorted by balance and age, another one surfaces — an invoice stuck for 632 days at a client with a lifetime habit of paying 8.4 days early. That client does not need a collections call: there is a disputed invoice nobody closed.
The datum that orders the queue correctly — how each client has always paid — was in the ERP. What did not exist was a way to ask for it without depending on another department.
The five collections questions
How it would reach the person asking
zQuestions to the ERPread-only
How much is overdue and uncollected?
486 invoices are overdue and uncollected, worth ARS 1,528,080,710.96: 30.1% of the open balance.
486 invoices are overdue and uncollected, worth ARS 1,528,080,710.96: 30.1% of the open balance.
To audit: the query that computed the answer
WITH abiertas AS (
SELECT total - cobrado AS saldo, dias_vencida
FROM facturas_al_corte
WHERE fecha_cobro IS NULL
)
SELECT SUM(CASE WHEN dias_vencida > 0 THEN 1 ELSE 0 END) AS facturas_vencidas,
ROUND(SUM(CASE WHEN dias_vencida > 0 THEN saldo ELSE 0 END), 2) AS saldo_vencido_pesos,
ROUND(100.0 * SUM(CASE WHEN dias_vencida > 0 THEN saldo ELSE 0 END) / SUM(saldo), 1)
AS pct_del_saldo_abierto
FROM abiertas;
What can be delivered
Above is what was done. What follows is what can be delivered.
Entry and diagnosis
Diagnostic
Says whether there is a project or a minor adjustment. Within a week it delivers one page: the question, whether it can be answered, what it depends on, the next step and at least one thing that will not be done.
Audit: what each question costs today
For each number that gets asked for today, it measures what it costs to obtain: how many times a year it is asked, how many days it takes, who puts it together and which decision gets made in the meantime. In two to three weeks it delivers the list of questions with the cost of each, the measured starting point any improvement is compared against, and one question chosen to be solved in the following four weeks.
Data that already exists
A catalogue of approved metrics over the database you already have
For figures that change depending on which dashboard you look at. Each metric is written once — what it means, the query that computes it and who approved it — and the system answers only from that catalogue, like the one above. Delivered in parts over four to eight weeks.
Work-queue prioritisation
Orders a queue — collections, claims, bounced cheques — with written rules: who gets attended to first and why. Within weeks it delivers the ordered queue, the rules and the figures that go with it, all recomputable whenever needed.
The report that builds itself
Replaces the report someone builds every month by copying from several sources. The queries are fixed and carry a cut-off date, and the document comes out the same every time it is run. Delivered in days to two weeks.
Data between systems
The bridge that replaces a manually copied spreadsheet
Connects two systems that are kept in sync by hand today. Within weeks it delivers the process running: if a transfer fails it retries; every movement is logged; and there is a written rule for what gets rejected. It includes maintenance, or an agreed date on which it stops running.
Your systems, usable from other tools
So that an assistant or another tool can use what the systems already do — check stock, load an order — without copying the database to another platform. Within weeks it delivers those operations published, with permissions per operation and a log of who called what.
From documents to data, with human review
Turns one type of document — invoices, delivery notes, orders, statements — into loadable data. Within weeks it delivers the process, which sorts each document into one of three: loaded, for someone to review, or could not be read; and measures how many fall into each.
What sustains each delivery
Handover and training
So the process does not depend on whoever built it. Within the project it delivers the documentation, runs anyone can repeat, and sessions until someone at the company operates it unaided.
Measurement and maintenance
Detects when something changes — a table, a service, a credential, a business criterion — and fixes it. It delivers, continuously, measurement against the starting point and maintenance, with a response window agreed at the outset.
It picks among the catalogue’s definitions. It does not improvise.
The question is written in plain language. The model writes no new queries and reads no tables: it picks among the catalogue’s definitions, the query runs on a copy of the company’s database, and the answer comes back with the query that produced it.
Definitions are written once
What “revenue” means, what counts as an overdue invoice, how lateness is measured: each definition is written down, with its query and who approved it. The argument happens once, over the definition — not at every meeting.
The model picks, it does not invent
Given a question, it picks which of the catalogue’s definitions answers it. It writes no new queries, so the same question always uses the same definition.
Outside the catalogue, it does not answer
If the question falls outside every definition, the system says so instead of improvising. That is on purpose: an improvised query can give a different number each time.
What gets installed
What is delivered is a system, not a list of queries: the place where questions are asked, and the catalogue of definitions that answers them.
Where you ask
On a screen like the console above, or in the chat the team already uses — WhatsApp, Slack, Teams. That is decided at the diagnosis, by where the person who will ask actually works; the system behind it is the same.
Who asks
Anyone on the team with access, with no SQL and no knowledge of the tables. They write the question in plain language and get the answer; the query sits underneath for whoever wants to check it.
Where it runs
On a copy of the ERP tables, taken with a read-only user and loaded into a separate database; the ERP is not touched. The model sees the question and the catalogue of definitions, not the tables; the detail is below, under security.
How a question gets added
The definition is written, approved, and available that same week. The catalogue belongs to the company, and the system keeps running once the work is over.
How company information is protected
Information handling is defined before work starts. Database rows, catalogue queries and query results require separate treatment.
The rows do not leave
The system sends no invoices, clients or cheques to any model. The model sees two things: the question as written, and the catalogue of definitions — names, names and descriptions. With that it picks. It reads no tables.
Queries run on a copy, not on the ERP
The ERP is not queried live. It is read with a read-only user and the tables that are needed are copied into a separate database, built for this, where the definitions run; the copy is reloaded when the company asks. The ERP is neither touched nor slowed down. Where that copy lives is set in writing before work starts: on the company’s network, or on a machine the company authorises. The only thing that comes back from each query is its result. If a result includes client names, that information does leave; which is why it is decided, metric by metric, which ones return totals and which ones return names.
What the model does
A language model is used for two things: picking which definition answers the question, and writing the answer. It computes nothing: the numbers come from the query. The account is in the company’s name, with no training on its data and the logs in view.
And the paperwork
A non-disclosure agreement signed before the first session, not after. Named credentials, never shared. Every query is logged — who asked, which query ran and how many rows it returned — and that log belongs to the company. On the last day the credentials get revoked and the system keeps running.
Four steps. The first one is free of charge.
The work is engaged in stages, with a fixed scope and a price agreed in writing before work starts. There is no hourly billing. The table sets out what each step answers, how it is engaged and how long it takes.
What does starting cost
Nothing. Step 0 — the diagnostic — is free of charge: one conversation and one written page.
When is the price known
After the diagnostic, in writing and before work starts. Each step’s price is put in writing at the end of the previous step.
What commitments exist
The engagement terms and committed timeframe of each step.
step
what it answers
billing
timeframe
0Diagnostic
Whether there is a case. Two hours with whoever knows the database, and one page in writing: what was found, plus the scope and price of the next two steps.
no chargeone conversation and one written page
one week
1Audit
What each question costs today: how many times a year it gets asked, how many days it takes, who puts it together. That measured starting point is what everything after it is compared against, and it remains even if nothing follows.
fixed scope
2 to 3 weeks
2One process
The chosen process ends up installed — the screen or chat where questions are asked, and the catalogue of approved definitions — measured and operable by the company’s own team, delivered in parts: each approved metric is live that same week.
fixed price, agreed before work starts
4 to 8 weeks
3By result
A percentage of the saving measured against the audit’s starting point. Without that starting point there is nothing to measure against, so this step is not sold on its own.
a single written percentage + a monthly base fee
12 months
Each stage has a fixed scope and a price agreed in writing before work starts. There is no hourly billing; a changed requirement is handled through a written scope change.
Engagement terms
Each stage is engaged with a fixed scope, fixed price and timeframe agreed in writing before work starts. There is no hourly billing. The diagnostic is free of charge and defines the following stages; any later change requires a written scope amendment.
What the price depends on
How many systems need connecting — the factor that weighs most.
What state the documentation of the current process is in.
How many metrics need defining, arguing over and signing.
The free diagnostic identifies those variables and concludes with a proposed scope, timeframe and price for the following stages.
Frequently asked questions before engagement
Doesn’t Copilot, or the Power BI assistant, already do this?
They do something similar, with one difference: those write the query on the spot; this one picks among definitions written in advance. An assistant writing queries over a database of more than 200 tables has to guess where the data lives and what the question means, and can answer differently each time. That distributor’s problem was not a missing tool: nobody had written down what “revenue” means. An improvising assistant does not solve that. And if the company buys that licence tomorrow, the written definitions work inside that tool too: they are documented definitions and queries.
Does the data need to be tidy before starting?
The data is usually there; interpreting it is the hard part. The case’s ERP has more than 200 tables, cryptically named columns and dates stored as zeroes, and has run like that for more than ten years. The datum that ordered the collections queue correctly had been there since day one. Tidying first is not needed: that is the part of the work being done, and the most expensive one — the cost of these projects is almost never the model; it is connecting with what is already there. And if a datum genuinely does not exist, the diagnostic says so in writing, naming the missing table.
A question that cannot be answered today.
Four fields. A person reads them and replies within two business days — including when the answer is that it is five minutes of work and there is no project. The diagnostic is free of charge and ends in one written page.
The last two fields are what it takes to reply with something concrete in the first answer.