Natural-Language Financial Query Automation: Ask in Plain Words, Grounded in Real Numbers

Letting someone ask a financial question in plain language is genuinely useful — nobody wants to build a filtered report just to find out how much they spent on one category last quarter. But a financial answer is exactly the wrong place for an AI model to guess: an invented number that sounds confident is worse than no answer at all, and sending an entire raw financial ledger to a third-party model just to answer one simple question is a far bigger privacy exposure than the question requires.

A genuinely useful natural-language financial answer needs a real, computed summary behind it — totals, categorized breakdowns, month-by-month trends — because an AI model has no independent access to a business's actual numbers and cannot answer honestly without them. But handing that model direct access to the full underlying data solves the accuracy problem by creating a much bigger one: raw financial records routinely contain client names, tax identification numbers, and e-mail addresses that have no reason to ever reach a third-party model just to answer "what was my biggest expense category." The two goals — a genuinely accurate answer and a genuinely private one — both require the aggregation to happen locally, before anything is sent anywhere.

The moment a question is asked, the browser itself — not the AI model — computes a summary directly from the invoices, payables and categories already loaded on the reports screen: total revenue and expenses actually paid, the realized balance, what is still outstanding to receive or pay, counts of overdue items, up to twelve months of monthly revenue-and-expense buckets, and the top categories by total on both the revenue and expense side. No client name, tax ID, or e-mail address is ever part of that summary.

Only that aggregate — never the underlying records — is sent, along with the question, to a server-side function that calls an AI model with an explicit instruction: answer only using the numbers in the provided summary, in plain language, and if the summary does not contain what is needed to answer, say so directly rather than guess. The model runs at a low creativity setting, favoring a consistent, grounded answer over an inventive one, and the question and the size of what can be sent are both capped, with a hard timeout on the whole exchange. The function itself never queries the database directly — it only ever sees what the browser already computed and chose to send, and it requires the person asking to be authenticated.

On the reports screen, someone types "how much did I spend on marketing this year?" — the browser's summary already has a marketing category total among its top expense categories, so the answer comes back with the actual figure in seconds. They then ask "what's my customer churn rate?" — a question the loaded financial summary has no data to answer, since it only covers revenue, expenses and categories. Rather than guessing at a plausible-sounding number, the answer states directly that the loaded period does not have that data, exactly as it was instructed to when the summary does not contain what is needed.

A quick financial question gets answered in plain language, from real numbers, without anyone building a one-off report or exposing anything beyond the aggregate figures the question actually needs. Because the model is instructed to admit what it does not know rather than invent an answer, a "no data" response is a trustworthy signal to go check elsewhere, not a false confidence that later turns out to be wrong.

A question that needs client-level or transaction-level detail — "which specific invoice from this client is overdue" — will not be answered by this mechanism, since the summary sent to the model is deliberately aggregate-only and never includes individual client or transaction identifiers. A question about data outside the twelve-month window or outside revenue/expense/category totals will correctly come back as "I don't have that," not as an approximation.

The obvious way to build financial Q&A is to hand an AI model direct access to the underlying records, trading privacy for convenience and risking a confidently wrong answer when the model fills a gap with a guess. Centriu Gauge instead computes a genuine aggregate — never a client name, ID, or raw transaction — locally before anything is sent, and instructs the model explicitly to admit the limits of what it was given, so an honest "I don't know" is a real, expected outcome rather than a failure to work around.