A sale sometimes stalls on a missing tax field, an expired certificate, or a rejection message that never reaches the right team in time. So evaluating an e-invoicing platform should not be settled by a slide deck or a general promise of a connection to the Authority. The practical question is: does the invoice stay issuable, traceable and auditable when the rules change, the load rises, or the Authority rejects a critical document? The only way to find out before you sign is a limited trial with realistic data.
The selection criteria themselves — what a provider should offer and the questions to put to it — are covered in how to choose a ZATCA integration provider. This article is about the next step: making the provider prove what it says, not just explain it.
What does the trial measure?
The right comparison measures operational ownership, not feature availability. Two platforms may both show a QR code, sealing and validation, but the difference appears when a document is rejected, an external service goes down, or an entity moves into a new Phase 2 wave.
In a mature setup the document arrives from your system in one format, is normalised and validated, sealed with protected keys, then submitted for clearance or reporting. A clear status then returns to the source system, with a record showing what was sent, when, and why it was accepted or rejected. If the platform hands responsibility for any part of that path back to your team when something goes wrong, that is not full automation; it is an integration that needs a parallel operations team.
Prepare the trial before you start
- Realistic data, with the sensitive parts removed: invoices from your actual transactions with customer details masked, including discounts, exemptions and credit notes, not just a simple sales invoice. Check your data's readiness before judging the platform.
- The test environment, not production: the trial runs in the sandbox, and you should know in advance whether it is billed.
- A joint team: someone from finance to judge how clear the statuses and rejection reasons are, and someone from IT to judge the interface and the logs.
- A written scorecard: what result is acceptable for each test, and how long diagnosis is allowed to take.
Five tests before you sign
1. A valid invoice through to its final status
Send a valid invoice and receive its final status inside your own system, not only in the provider's portal. Look at the actual request: does your team work with one structure such as JSON, or does it have to build a UBL document for each invoice type? Does the status arrive by a webhook your system can consume automatically? A technically successful request is not an accepted invoice.
2. A rejected invoice and its resubmission
Send an invoice with a deliberate tax error. Does an understandable message tie the error to the field and the rule? Does the system tell a source-data error from a technical one? After the fix, is the invoice resubmitted safely, without a duplicate and without breaking your document sequence? Compare the messages with what you know of the most common rejection errors.
3. An outage or expired certificate, then recovery
Ask for a simulated outage or slow response from the Authority, and an expired or soon-to-expire certificate. What happens to documents during the outage? Do they wait in a controlled queue with a clear status and resume after recovery without loss or duplication? Does the system warn you before the seal certificate expires? What should happen is covered in handling invoices when ZATCA is down.
4. A complete audit trail for one document
Pick one document and ask for its complete trail: the original request, the validation result, sealing, submission, the Authority's response, and any retry or authorised change. Can it be traced from your internal number to the Authority's reference without searching separate files? Can it be exported for your auditor? What must be kept by law is explained in invoice storage and audit readiness.
5. Access separation between two entities
If you run more than one company, set up two entities and ask for proof that a user or access key in the first cannot see the second's documents or use its certificate. Test what an AI assistant or automated tool can actually do: is it limited to reading? Does a production write require a recorded human approval? See invoicing across several legal entities and AI in e-invoicing, under control.
What to watch during the tests
Don't watch only the final result; watch:
- Time to diagnosis: how many minutes did your team need to understand a rejection?
- Who had to step in: your team, the provider's support, or no one?
- How clear the status is to finance without IT translating it.
- Behaviour under load: ask how high volumes are processed asynchronously without blocking the source system, and what happens at peak.
Review the pricing against the trial
After the tests, ask: what would all that have cost you? Pricing on submitted documents alone has you paying even when validation fails or the Authority rejects an invoice whose error should have been caught before submission. The fairer model ties cost to documents the Authority actually accepted, and does not bill rejections, validation failures or the test environment. If you have not yet settled between a platform and building the layer in-house, read build or buy your ZATCA integration?.
How this looks in alFatora
You can try the path on alFatora Connect yourself before any commitment:
- The sandbox is free and unlimited, so you can try valid and rejected invoices and resubmissions at no cost.
- One JSON shape and a status for every document by webhook, including awaiting clearance when the Authority is slow.
- A mandatory idempotency key makes resubmission safe, and scoped access keys for each job.
- A fixed audit trail linking the request, validation, sealing, submission and the Authority's response.
- In production you pay only for what is accepted: credits are spent on documents the Authority accepts.
No platform is right for every company. But a sound choice does not reward whoever promises the most features; it rewards whoever states where its responsibility starts and ends, and proves the invoice stays under control when things do not go to plan. Make the trial about rejection, audit and recovery, because that is where a platform's value shows.
Frequently asked questions
How do I test an e-invoicing platform before signing?
With a limited trial in the sandbox using realistic data with sensitive details masked, covering a successful submission, a rejection, an outage, the audit trail and entity separation, with a written scorecard for each test.
What matters most to watch during the trial?
How long a rejection takes to diagnose, who had to step in, how clear the status is to finance, and how the platform behaves through an outage and recovery without loss or duplication.
Should I pay for rejected invoices during testing?
You should not. The fairer model ties cost to documents the Authority accepted in production, and does not bill rejections, validation failures or the test environment.
Was this useful? Review alFatora on Google.
