How this handles your data

This is the Ledger Solutions takeover review and invoice queue, built by Noorflows. This page says where data lives, who can reach it, what is kept, and — the part most pages leave out — which independent security reviews we have not had.

We hold no SOC 2 report, no ISO 27001 assessment, and no third-party security assessment of any kind. Nobody outside Noorflows has assessed these claims. If your procurement process requires one, we do not meet it today, and we would rather you learned that here than three weeks into an evaluation.

Where the data lives

The demo you are looking at holds invented records only.: Every company, person and record in it was made up for the purpose. No real record has ever been copied into it, for any reason, including our own testing.
A live system for a company holds that company's data and nothing else.: Not one database with a column saying which customer a row belongs to — a separate store, separately deployed. A shared database with a filter is one mistaken query away from showing one customer another customer's records, and that mistake cannot be undone by apologising.
The demo and the live system are kept separate from each other too.: A build running for a company holds its own store, and this demo holds another. They never touch, and nothing has ever crossed between them in either direction.

What the takeover review reads

It reads a copy of the books, and it changes nothing in them.

A takeover review looks at a whole client ledger — accounts, transactions, suppliers and reconciliation history. That is more than an invoice queue ever sees, so it is worth being plain about: nothing is edited, merged or re-coded, no entry is posted, and no message is sent to anyone. Every finding is a recommendation for a person to act on.

When contact has to stop

There is a switch that stops everything going out, and it asks for no reason.

A practice can be under an obligation to stop contacting a client and not to say why. While the hold is on, no question, reminder or message leaves the system. We record that a hold was placed and by whom, on a trail that cannot be edited or deleted — and we deliberately do not record why, because there is no field for it. That sentence belongs in your records, not ours.

This does not look for money laundering and has no view on whether anything is suspicious. A person in your practice decides when to switch it on.

Who can reach it

One set of credentials per build.: No key exists that can read across two customers. That is a property of how they are deployed, not a rule someone remembers to follow.
No personal data in shared logging.: A shared log is a shared database by another name. Logs carry references — an order number, a record id — never names, addresses or contact details.
Uploads are processed in memory and discarded.: Where a build accepts a file, it is read, used, and not written to disk. Nothing is kept to "improve the service".

What we do not do

We do not	Because
Train any model on your data	Your records are yours. Nothing you send is used to improve anything we sell to anyone else.
Send your data to a model provider unless the build needs one	Where a build uses a language model it is named on that build's page, and it only ever rephrases facts the code has already established.
Keep data after an engagement ends	The customer's data is deleted. Our own record of what we did — what was checked, when, and what it said — is kept for twelve months, because a report nobody can stand behind in a year is not evidence.
Move money, send messages, or take an irreversible action on our own	Every one of those ends at a person choosing it. This is the same rule in every build.

What is written down

A build running for a company keeps a record of what was checked, what the check said, and who decided what — with the version of the rules that applied at the time, so an old entry stays readable after the rules change. Entries cannot be edited or deleted. A record that can be tidied is one nobody can rely on, and the day it matters is the day somebody would most want to tidy it.

That record holds references, never personal details.

In this demo the trail is real — every hold is recorded and shown with it — but it lives in the page in front of you. It starts empty and it is gone the moment you reload.

What we would need before handling real records

A signed data agreement, before any access is given — not after. Where the data concerns people in the UK or the EU, that agreement has a cross-border section a lawyer has to complete, and it is the customer who is exposed without it, which is why their lawyer is the one who stops the deal. We do not accept access to a live system before it is signed.

Back to the demo · Plain text version of the demo page · Noorflows

Written 8 August 2026. If anything on this page stops being true, it is a defect and we would like to be told.