The Filter That Silently Excludes Money

The specific exclusions matter less than the shape they share, but they are worth naming separately because each has a defensible motive that made it look harmless on the day it was set. This is not a list of mistakes. It is a list of reasonable decisions that became invisible.

The reason these four belong in one article is that they do not have a direction. A filter that drops a branch and a filter that drops credit notes both make the number wrong, and they make it wrong in opposite directions. A reader who learns only that 'the report is filtered' has learned nothing they can act on, which is why the honest fix is not more filters and is not a warning icon.

Everything below is invented so the arithmetic is checkable. The invoices, the sites, the cancellation and the credit note are ours; none of it is a customer or a measured result. The 18% rate appears only to keep the totals verifiable by hand, and the rate and treatment that actually apply are for your own chartered accountant to confirm.

Now the report. The saved view is called HQ Active Revenue, and it carries three conditions, each of which was sensible when it was added: the site is HQ, the document is not cancelled, and the gross value is not zero. It does not mention credit notes, which is the point — nobody added a condition to exclude them. They fell out because a credit note is not an active invoice, and the filter was written in terms of what invoices are rather than what happened.

Two things in that table deserve to be read slowly. The first is the sign on the credit note row. Removing it does not subtract 9,440 from the total; it adds 9,440 back, because a credit note is a document that reduced the register and the filter is excluding it. So a single filter, applied for a reason that was entirely sound, makes this month's revenue look larger — while removing the plant site makes it look smaller by 41,300. The net difference of 46,020 is not a bias in either direction. It is the residue of four unrelated decisions, and it will be a different number next month for reasons that have nothing to do with how the business performed.

The second is that the reported figure is not wrong. Every document in the saved view genuinely was issued at that site and genuinely is active, and any accountant handed the rows would confirm them one by one. The report is a correct answer to the question it was built to answer. That is what makes it dangerous: it is defensible in a meeting, right up until somebody asks what it left out, at which point there is no version of the conversation that gets you the original number back without rebuilding the month by hand.

One more detail of the register is worth naming because it is invisible in the table. N-06 was cancelled on 14 November rather than deleted, and CN-01 is a document in its own right rather than a negative row attached to N-02. Both of those are the right shape: a cancelled document is still a document the business issued and withdrew, and a credit note is a separate document with its own number and its own date. Keeping them means the month can be explained. Deleting them, or folding a credit into a negative line on the original invoice, would make the register smaller and the history shorter, and both of those are trades this article is arguing against.

The question a reader has in a meeting is never 'is this number correct'. It is 'why is this number so small', and the two situations are indistinguishable from inside the number. Here are the three tests we would apply, in the order they fail most often.

The third test is the one that gets skipped, and it is the one that causes the argument that a reporting tool is unreliable. A number that changed because somebody corrected a filter is a number that changed, full stop, and it will be presented in a meeting as a business result. The person defending the business did not do anything wrong and cannot win the argument, because the actual cause is not in the number and never was.

The goal is not to remove saved views. Saved views are one of the genuinely useful things a reporting tool can offer, and a business with a plant and an office will want a view for each and a consolidated one above them. The goal is that a view stops being a private convenience and becomes a published definition, which means it acquires four things it does not have by default.

None of this requires a particular product. It requires a decision that filters are part of the number, made once, and then the discipline to keep the decision current. The discipline is the hard part, because a definition that nobody maintains is worse than no definition: it is a number people have stopped questioning, which means the first real change to it goes unnoticed for as long as the number looks plausible.

There is one more way a number ends up answering a different question from the one its reader assumes, and it does not involve a single condition. It is the choice of which state to report, and it is invisible in the figure because all four states are real numbers produced from the same records. Quoted, billed, collected and outstanding are four different claims about the same commercial relationship, and the words revenue, sales and takings each point at a different one of them depending on who is speaking.

This matters most where a report computes outstanding. Outstanding is not a stored figure. It is the invoice total minus the sum of live allocations, recomputed from the records every time the report is run, and a payment is a separate record from the invoice it settles. That is the correct design, and it has a consequence worth stating plainly: there is no stored paid flag to go stale, but there is also no single stored number that is revenue. Any figure is a projection over a stated set of documents and allocations, and the reader has to be told which set. A tool that shows a paid tick is showing a conclusion. A tool that shows the allocations behind it is showing the argument.

Three boundaries. First, making the filter part of the number does not make the number correct — it makes the number arguable, which is a lower and more achievable bar and the one that actually matters in a meeting. Deciding which documents count as revenue is a business and accounting judgement, and the treatment of credit notes, advances and part-payments in particular belongs to your own chartered accountant rather than to a software default. Second, a filter cannot rescue a report built on records that do not join. If the same customer exists twice, the report will faithfully sum both and hand you a total that is arithmetically impeccable and commercially meaningless, and that failure sits upstream of every filter you could add. Third, NoxOrigin reports are computed from the records it holds, and the same discipline applies downstream: the exports are inputs to your accountant's work rather than a substitute for it, and NoxOrigin does not file GST returns or any other statutory return.

Nothing here is measured. We have no count of how many saved views in the wild carry an undocumented condition, no measured share of reported figures that cannot be reproduced from their own rows, and no data on how often a filter change is mistaken for a business result. Every figure in the tables above is arithmetic we constructed so that a 46,020 difference could be traced to four documents, and the invoices, sites and outcomes are invented. The instrumentation we would want before making a claim about this is unglamorous and specific: the share of figures that can be reproduced from the rows behind them, the number of saved views with a named owner, the count of configuration changes made inside a closed period, and the number of month-on-month comparisons where the cause of the difference was identified as a filter rather than as performance. Until those are counted, the argument is structural, and the test that costs you nothing is to rebuild last month's reported figure from the register yourself.