Who really posted this
The ledger records a user ID, which may be a batch process, a shared service account or an integration. The approval may have happened in an email the ledger never sees.
IndustriesInternal audit
The entry was ordinary.The person posting it was not.
Correct account, reasonable amount, weekday, within authority. It passes every test you run, because every test you run is a test about the entry. Nexyron tests the person.
Your whole toolkit shares one assumption.
Population testing, duplicates, gaps, Benford, round numbers, thresholds, weekend flags, unusual account pairings. The tools are good, the methodology is taught, and the profession has spent thirty years refining it.
Every one of them takes the transaction as the unit of analysis. The question is always some version of: is this entry unusual.
Is the person who posted this entry behaving unusually?
Not unusual in amount. Unusual for them. This poster has never touched this counterparty. This approver has never approved at this hour. This person's rhythm changed six weeks ago and has not come back.
Does the document contradict the entry
Matching a number to its support is solved and well served. The question you have is the inverse: where do documents disagree with the ledger.
Who can do what across systems
Separation of duties inside one system is that system's control. A combination that is only toxic across two is nobody's control at all.
Somebody doing something they should not is usually careful about the amount and careless about the pattern. Your tests are built to watch the amount.
What Nexyron does instead
Change the unit of analysis, and everything else follows.
Nexyron takes the same extract you already pull, plus the correspondence archive, the entitlement exports and the contract set, and derives one connected model in which the poster and the approver are subjects with histories rather than fields on a row.
Time is a property of that model, so a person's rhythm, the interval between an email and a posting, and a three-year absence of contact with a counterparty are all the same kind of question, asked in one query.
Meaning-based search reads the contracts and the correspondence beside the ledger they govern. Which is what turns “where do documents disagree with the postings” from a manual sample into a computation over the population.
Your analytics tools keep doing population testing, and they are better at it than we are. Nexyron answers the question that comes after it.
A simulated review
Constructed to show the method. No client, no engagement, no benchmark.
- 01
Change the subject
Every poster and approver becomes a subject with a history: which accounts, which counterparties, at what times, in what rhythm, with whom approving. Each entry is then assessed against its poster's own pattern rather than against a population threshold.
Many conventionally flagged entries turn out to be entirely ordinary for the person who posted them. Which is why the same names come back every year and the same hours are spent clearing them.
- 02
One entry
Routine account, routine amount, a Tuesday, within authority, correctly approved. Flagged because the poster has never used that counterparty in three years, the counterparty was created eleven days earlier by a different user, the approver has approved four of this poster's entries in three years and all four in the past month, and the posting time falls outside this poster's established pattern.
No fact is suspicious on its own. Together they describe a working relationship that did not exist six weeks ago.
- 03
Who actually approved it
The ledger records a shared service account. The correspondence archive holds an approval for that exact amount and counterparty, sent by a named individual who is not who the ledger implies. The control operated somewhere the ledger cannot see.
- 04
Where documents contradict
The contract specifies payment terms and a discount schedule. The posting history follows neither. Not a documentation exception. A difference between the agreement and the behaviour.
- 05
Across systems
Entitlements from finance, procurement and payments in one view. Within each system every conflict is controlled. Across them, a handful of individuals can create a supplier in one and release a payment in another, and one of them has exercised both sides.
- 06
What is not in the population
A document number range with a gap in one entity, one subsidiary ending three weeks before year-end, a class of entries the extract parameters silently excluded. None of the three indicates wrongdoing. All three change what the review is entitled to conclude.
The same extract. A different unit of analysis.
The subject moves from the entry to the person
Everything else on this page follows from that single change.
Behaviour is relative to the individual
A test asking whether this person has ever done this before finds what no threshold ever will.
The approval chain becomes complete
Correspondence and ledger in one analysis, which is where the real approval very often lives.
Documents can contradict, not merely support
The inverse of matching, run across the population rather than a sample.
Completeness is stated in week one
Rather than discovered in the closing meeting.
The dimension nobody in this category occupies
Did the control you recommended last year work?
Internal audit issues findings, management implements remediation, and next year somebody reports that the remediation is complete. Complete is not the same as effective, and the difference has never had an instrument.
Nexyron carries 42 causal and decision procedures on the same graph the entries live in. Comparable populations that did not receive the control are identified rather than assumed. Uplift is estimated rather than asserted, and where the comparison cannot be built honestly, the engine declines.
No audit analytics product on the market answers this. It is also the single most useful thing an audit committee could be told.
Where the work compounds
Year two starts from year one.
An analysis worth keeping becomes a Lens: a written contract between a subject and an analytical purpose, which runs again next year against current data without being rebuilt by whoever inherited the file.
Reports, features, knowledge assertions and recorded decisions stay addressable and searchable. The second question starts from what the first one built, which is the only version of this that accumulates instead of resetting every audit cycle.
Running it
The extract never leaves the organisation.
General ledger detail, correspondence archives and entitlement data are among the most sensitive material an organisation holds, and moving them into a vendor environment turns a two-week analysis into a six-month approval.
Nexyron installs like an application and runs the entire engine on hardware you already own. The privacy review gets short, because the data never leaves the building.
Take last year's flagged population.
And the handful that were actually written up. For each one, ask the question the tests cannot: had the person who posted it ever done anything like it before?