Judge a regulatory reporting tool on eight things: whether it validates with fixed rules or merely stores data; whether a named person approves each filing and the approval is evidenced; whether the evidence verifies independently; where the data lives and who else can reach it; whether it actually transmits filings or only prepares them; how it has handled a real rulebook change; how you would get your data out; and what it costs at your volume. Ask for artefacts rather than assurances — a rule catalogue, an approval record, an export file. Every one of these questions has an answer a vendor can show you, and a vendor who can only describe it is telling you something.
Buying software for a regulated filing is not like buying most software. The failure mode is not that the team dislikes the interface; it is that a submission is rejected, or accepted and later found wrong, and the firm — not the vendor — answers for it. That asymmetry should shape the whole evaluation. You are not buying features. You are buying the ability to demonstrate, later and under pressure, that a number was right and that a person stood behind it.
These are the questions worth asking. They apply to us as much as to anyone else; the last section says where we would tell you to buy something different.
1. Does it validate, or does it just store?
Most tools in this category are databases with a regulatory-looking schema. They will hold a register happily and tell you nothing about whether it will be accepted.
How to test it. Ask to see the rules. Not a screenshot of a green tick — the actual list of checks, with identifiers, and which published supervisory validation rule each one corresponds to. A vendor that validates can show you a catalogue. A vendor that stores will talk about dashboards.
The answer that should worry you: “Our AI checks it for you.” A model can flag an anomaly; it cannot give you the same answer twice on the same input, which is what a filing needs.
2. Who approves the filing, and can you prove it afterwards?
Regulators do not accept submissions from software. They accept them from a firm, and somebody at that firm carries the consequence.
How to test it. Ask what happens between the data being ready and the filing leaving. There should be a halt, a person, and a record naming them. Ask to see the record — not the screen, the artefact you would hand an auditor eighteen months later.
The answer that should worry you: An “auto-approve for trusted runs” setting. It will be switched on within a quarter, and the first time it matters nobody will be able to say who approved what.
3. Can it prove the number, not just show it?
The question an auditor asks is never “what is the figure”. It is “where did this figure come from, and has anyone changed it since”.
How to test it. Ask whether you can export the evidence and verify it independently — outside the vendor's software, ideally with no network. Tamper-evidence means something specific: a hash chain where altering history breaks the chain and the break is detectable.
The answer that should worry you: “Full audit trail” meaning a table of log lines that the same database write could edit.
4. Where does the data actually live, and who else can reach it?
Contract data, vendor lists and tax records are among the most sensitive things a firm holds, and this category collects all three in one place.
How to test it. Ask for the sub-processor list, the hosting region, and what happens when the answer has to be “nothing leaves our network”. A genuine offline deployment has no phone-home licensing and no telemetry, and you can test that with a packet capture rather than a promise.
The answer that should worry you: An air-gapped edition that still needs to reach a licence server “just occasionally”.
5. Does it file, or does it prepare?
Some regimes publish a submission API. Several do not, and no software can file into a channel that does not exist.
How to test it. Ask, regime by regime, whether the product transmits the submission or produces a package you then file yourself. Both are legitimate. Only one of them is what “fully automated filing” implies, and the gap between them is weeks of somebody's time.
The answer that should worry you: A single “automated filing” claim covering a portfolio of regimes, some of which have no regulator API at all.
6. What happens when the rulebook changes?
It will. Templates get revised, thresholds move, policy statements come into force with a date attached.
How to test it. Ask when the vendor last shipped a change in response to a regulatory update, and how you found out. Then ask what it cost you. A specific, dated answer is worth more than any roadmap.
The answer that should worry you: “We monitor regulatory change” with no example of having done anything about one.
7. Can you leave?
Compliance data outlives compliance vendors, and the record has to survive the relationship.
How to test it. Ask for the export format before you sign, and check it is something you could actually use elsewhere. Ask how long you have to retrieve it after termination and whether that is in the contract or in a support person's goodwill.
The answer that should worry you: Export as PDF, or as a proprietary format with an importer only the vendor ships.
8. What does it cost at your volume, not at the demo's?
Per-seat pricing hides the cost of a regime where the work scales with entities, arrangements or clients rather than with people.
How to test it. Take your real numbers — client count, arrangements, entities, registrations — and ask for the figure. Then ask what happens at twice that. A vendor who cannot price your actual shape without a call has a pricing model that depends on you not comparing.
The answer that should worry you: “Contact us” as the only pricing signal, or a metered model where you cannot recompute the bill from your own records.
Where this product is the wrong answer
A buyer's guide written by a vendor is not neutral, and pretending otherwise would undermine the point of the exercise. So, plainly, the cases where Qgentic is not what you want:
- One VAT registration and a simple set of books. If you file a single nine-box return from a tidy spreadsheet, a low-cost bridging tool is a better fit than a validation platform. The engineering here is aimed at firms where the cost of an error, or the volume of filings, justifies it.
- You want the work done, not the software. Qgentic prepares filings; it does not act as your agent, form a view on your tax position, or take responsibility for a judgement call. If what you actually need is a practice or an adviser to own the outcome, engage one — some of them run Qgentic underneath, which is a different arrangement entirely.
- You need a filing route we do not have. Where a regulator publishes no submission API, we prepare the package and you file it through your existing channel. That is stated on every pack page. If a vendor tells you they file directly into one of those regimes, ask them to show you the endpoint.
- You want a single tool for everything a compliance function does. This is regulatory reporting: registers, returns, evidence. It is not a policy library, a GRC workflow suite, or a controls-testing platform, and a bundle that claims all of it usually does one of them properly.
Where it does fit — several regimes at once, a real audit exposure, data that cannot leave the building, or a client book big enough that quarterly filing has become a staffing problem — the eight questions above are the ones we would want you to ask us.
How these guides are researched and reviewed: editorial standards. Terms used above are defined in the glossary.