Three records of the same deal, held in systems that nothing forces to agree. We reconcile them from your own data, classify every difference and price the ones we can explain. You get a register your controller can check row by row.
Quote to cash · Fixed fee · Read-only access
Four to eight weeks · We do not sell the fix
The problem
A deal is recorded across a CRM, a quoting tool, a folder of signed PDFs, a billing system, an ERP, a product event stream and a bank account. Each system holds part of the record. None holds all of it. Each one balances against itself, so each one looks correct.
Month-end reconciles billing to the ledger. It ties out whether or not the invoice matched what the customer actually signed. A difference appears only when two systems are put side by side, on the same contract, on the same field, on the same date.
Nothing throws an error in the meantime. A subscription loaded on a twelve month term where the contract says thirty-six is valid data. An included quantity with no overage charge behind it is valid configuration. Each system does exactly what it was told. An invoice that was never raised has no number, no date, no owner and no exception queue.
Nothing enforces the joins either. An account ID pasted into a billing metadata field. A customer number an integration wrote once and never revisited. An email domain. A filename on a signed PDF. Usually no single person owns the mapping end to end.
What we do
Noetra is a diagnostic practice. We assemble the record of what was agreed, out of contracts, order forms, signed amendments, approval records and the price book in force on the day. Then the record of what was billed, from the billing system and the ERP. Then the record of what was collected, from the bank and the payment provider. We join the three at line level.
There is no universal key across those systems. Building the joins is most of the work. Records that will not match are reported as a finding in their own right, with the reason they would not match.
Every difference is classified before it is priced: which two records disagree, on which field, and what allowed them to disagree at all. Where we cannot name the mechanism, the difference is reported as unexplained and it stays out of the total.
We report overbilling as prominently as underbilling. A customer charged list price where a discount was approved is money you owe back. A report that only ever finds money in your favour is not a measurement.
We do not implement the remediation, resell a billing platform, or take a share of what you recover. Nothing in our fee moves with what the report says. A finding is only worth something if the person who found it had no reason to inflate it. That independence also makes the register safe to circulate internally. It is not a sales document.
What we look for
A finding you cannot trace is an opinion. Each of these produces record identifiers on both sides, an expected value, an actual value and a number.
Migration ↔ Everything
Group accounts by the date of your last billing or ERP cutover and compare their error rate against the rest of the book. Cutover errors tend to be systematic rather than random, so they cluster. This is usually the first cut worth running, and it is why we ask when you last changed platform.
CPQ ↔ Billing
The approval record says twenty percent. The live rate plan charge says twenty-five. We recompute list price against approved discount for every line, in both directions, because list price charged where a discount was approved is money you owe back.
Contract ↔ Invoice
Sum the invoice lines across the term and compare them to the contracted amount. Proration and stub periods create legitimate noise, so we set a tolerance and we tell you what it is.
Product ↔ Billing
Per account, per meter, per period. Persistent gaps between the event stream and the billed units are unbilled consumption. This is the check where the customer identifier usually breaks, and finding that is half the value.
Contract ↔ Renewal
Index-linked and fixed escalators live in prose, not in a field. We read them, compute the renewal price they required, and compare it to what you charged. We check which index and which reference month, because both are routinely wrong.
Amendment ↔ Invoice
Upgrades entered six weeks after their effective date with no catch-up invoice. Downgrades credited past a non-reducible minimum. Add-ons that were never co-termed with the parent subscription.
Billing ↔ Product
Active entitlements with no active subscription. Margin you are paying for every month, and a data retention problem that we flag separately because it is not really a revenue issue.
Invoice ↔ Bank
Decline sequences grouped by reason. Soft declines are recoverable and hard declines are not, and treating them alike hides the real gap. We check that the dunning mail was actually sent, because usually the campaign was paused.
Invoice ↔ Delivery
Posted invoices with no delivery event behind them. With enterprise customers the usual cause is a missing or expired purchase order number that their accounts payable system rejects without telling anyone, so it reads as slow payment for months.
Invoice ↔ VIES
Zero-rated intra-community invoices with no dated VAT number validation kept from the time of invoicing. If the number was not valid then, the zero rating is exposed. Your tax adviser decides what that means. We report the invoices and the missing checks, under exposure we cannot price.
Billing ↔ Ledger
Opening deferred, plus billings, minus recognised, should equal closing deferred, per contract. Anything that does not tie is an error. This single assertion finds most of its category.
Pricing ↔ Contract
For every customer holding an MFN or price protection clause, compare their effective unit price against the lowest you sold to anyone in the same period. This is a liability rather than a leak. It is found by the same joins, and it has usually never been checked.
The full check list runs to around eighty. These twelve are the ones we run first.
Where the data comes from
Extraction is built per engagement and the time for it sits inside the scope. If your stack is not on this list, ask. The checks are the same. Only the extraction changes.
How it works
Four to eight weeks from signature. Access takes two to four of those weeks and waits on your IT and security teams. Analysis runs two to four weeks once the data is in. Anything that would push past eight gets cut from scope rather than extended.
What we need from you: one person who can approve access, a data owner per system, and roughly five to twenty hours of your team's time in total, most of it early.
Forty-five minutes, no charge. Which systems, how many active contracts, how much revenue is usage-based, and what prompted the question. No deck. An NDA first if you would rather talk about specifics.
Every system we are asking for, with one line on why it is needed and which objects get read. A list of what is out of scope. The deliverable, the fee and the end date. The fee is set by how many systems are in scope and how many contracts sit behind them, not by days worked. You get the number in writing after the scoping call, before any work starts, and it does not move afterwards.
Read-only credentials at least privilege, held by named individuals. Flat file extracts instead, if your security review prefers that. Where your environment allows it we work inside your own infrastructure and nothing leaves your perimeter. This is the step that slips, so it starts the day the scope is signed.
We build the joins first and give you the unmatched set early, because it changes what the rest of the analysis can honestly claim. Findings reach you as they land. There is no reveal at the end. Where a difference cannot be evidenced it is reported as unexplained rather than quantified.
Five findings, chosen by us, checked by your controller against the source systems before the register is finished. If one of our rules is wrong, it gets corrected here rather than argued about after delivery.
A findings register, one row per discrepancy, with the two systems, the field, the record identifiers on both sides, expected value, actual value and a confidence rating. It opens in a spreadsheet. Ranked by value and by effort to fix. A two page summary for whoever holds the budget. The detection logic, documented.
The total is split four ways and never blended: cash you can still invoice, recurring revenue you are undercharging from here forward, money you owe back to your own customers, and exposure with no reliable value such as VAT treatment or an untested price protection clause.
Then you revoke the credentials, we delete the working data, and you get that in writing. We answer questions about any finding for thirty days at no charge, because a register nobody can act on is not worth buying. After that we are done. Nothing renews and nothing is owed.
Data and access
It should be. You are being asked to let two people you have not met read your revenue systems. Here is what we can tell you, and what you can check yourself.
No write access, ever
We do not ask for it and we will not accept it if offered. That refusal goes into the engagement letter. A firm that cannot change your data is a smaller risk than a firm that promises not to.
Scoped to named objects
An integration user on a minimum access profile, with a permission set granting read on the specific objects we listed in the scope. Restricted API keys elsewhere. Every system we ask for carries one line saying why.
Your infrastructure first
Where a warehouse can carry the analysis, it runs inside it. Your compute, your logs, your off switch. The row-level data never moves. Contracts and signed amendments are the exception, because we have to read them. This is the standard offer, not a premium tier.
Verify it without asking us
Login history, query history and API logs are yours. Everything done under the credentials you issue appears in your own systems, during the engagement rather than after it. You do not have to take our word for any of this.
Two named people
Luis and Joshua are the only people who will hold credentials or see your data. Luis holds the eenmanszaak. Joshua co-founded Noetra and works on every engagement as an independent contractor, which makes him a sub-processor. He is the only person on the sub-processor annex. Everything else on it is infrastructure. No delivery team, no offshore analysts, no rotation. If that changes, it changes by written amendment before anyone new gets access.
What stops a copy leaving
Write access is the easy half. The harder question is what stops data walking. Full disk encryption on both machines, MFA on every account, no client data on personal devices or personal cloud accounts, and one isolated workspace per client that is destroyed at the end. All of it is written into the engagement letter.
We are not SOC 2 audited
We will not claim otherwise or imply an audit that did not happen. The stronger answer is that in the default arrangement your data stays in your systems, apart from the contracts and amendments we have to read. The engagement letter says where those are held, who can open them and when they are destroyed.
Most of this data describes legal entities rather than people. The personal data in it is limited to contact names on accounts, user records used for seat counts, and signer identities on envelopes. Seat counting works on salted hashes that you generate, and where a join has to run on an email address, it runs on the hash. That is pseudonymisation and not anonymisation: the hash is still personal data and it stays inside the Article 28 agreement. What it buys is that we never hold a readable customer email, which shrinks what a mistake on our side could expose.
An Article 28 data processing agreement, a record of processing activities and a named subprocessor list come as standard. Retention and destruction are written into the engagement letter before work starts, and deletion is confirmed in writing at the end.
The report is yours. We do not contact your auditor and we do not contact your customers. Findings go to the sponsor you name, and where a finding touches the sponsor it goes to a second recipient named at the same time. That gets agreed in writing before access is granted, while it is still a procedural question rather than an awkward one.
Who you would work with
Chief Executive Officer
Luis owns scoping, the client relationship and the reporting. Nine years in finance, from purchasing into finance operations, now a team lead and senior specialist. Most of his career has been spent on the operational side of revenue, which is where the errors are made and where they are found.
LinkedIn
Chief Technology Officer
Joshua owns the data, the joins and the detection logic. A master's in experimental particle physics and two years of doctoral research, then four years as an analytics engineer. He was trained to measure things and to account for the error in the measurement.
LinkedInGet in touch
The form is not connected yet, so please email us directly. That reaches Luis, and it is the same address the form would have used. luis@noetra.eu
The most useful thing you can tell us is when you last changed billing platform. Every migration leaves a cohort of contracts behind, and that cohort is where we start looking.
If you are not sure whether there is anything to find, that is a normal place to start from. Nobody knows until the systems are compared.
When the answer is no. If your contracts are simple, your book is small, or one system genuinely holds the whole record, there is unlikely to be enough here to justify the fee. You will hear that on the call, not after the invoice.