Security
Invoice processing touches financial data, supplier relationships and personal data, so security is part of how the system is designed rather than a feature list. This page sets out our security architecture, access-control approach, data-handling principles and environment separation — and is deliberately explicit about what we will not claim without confirming it for your deployment.
Security pages tend to be the least reliable pages on a vendor website, because the incentive is to list reassuring terms. We have taken the opposite approach: this page describes how the system is built and operated, and leaves anything that requires formal confirmation to the security assessment for your implementation.
None of that is a refusal to answer. Each of those points is answered directly, in writing, during the security review for a specific deployment — where an answer can be verified and relied on rather than simply read.
The architectural principles below shape how the system is put together, independently of any specific customer environment.
The system works with the data the invoice process requires. Narrower scope means less exposure and a simpler review.
Integrations and internal components are granted the narrowest access that lets the process work, rather than broad access for convenience.
Processing steps, decisions and exception resolutions are recorded, so that what happened to an invoice can be reconstructed.
Development, testing and production are kept apart, with production data not used casually for development work.
Access is granted by role. AP, buying, approval and administrative capabilities are distinguished, and actions are attributable to an identity.
Processing steps, decisions and exception resolutions are recorded so that what happened to an invoice can be reconstructed.
Data is processed for the invoice process it was provided for, kept logically separated between customers, with internal access limited to need and retention agreed rather than left open.
Interface transport, credentials and permitted scope are agreed with your IT organisation, and access is scoped to the data the process needs.
Development, test and production are distinct, and the approach is aligned to your own separation model — customer- and environment-specific by definition.
Layers describe how the system is designed and operated. Anything customer- or environment-specific — including data location — is confirmed in writing during the security assessment for your deployment.
Interfaces into your systems are part of this picture. How they are secured in practice — transport, credentials, permitted scope — is agreed with your IT organisation during implementation; see integrations.
Role-based access, so people and interfaces reach only the data their task requires, with actions traceable to an actor.
Data minimisation: invoice data is processed for the purpose it was received for, and handling specifics are agreed per deployment.
Development, test and production work is kept separated, and customer data is not used casually outside its environment.
Traceability of processing steps and interface activity, with contractual detail confirmed during a customer assessment.
No certification, encryption standard or service-level figure is asserted here; specifics are confirmed in writing per deployment.
Access control answers two questions for every action: who is doing this, and are they allowed to. Our approach is role-driven and configured for your organisation rather than assumed.
Which roles exist, and who may see and approve what, is set during implementation — the correct split depends on your organisation's segregation-of-duties requirements, not on a vendor default.
Invoice processing involves supplier data, commercial values, order information and — inside documents — personal data such as contact names. We treat all of it as production business data.
Formal data-protection terms, including a data processing agreement where required, are part of the contract. Our published privacy terms are on the privacy page.
Separating environments is one of the plainest ways to reduce risk, and it also makes integration work safer to carry out.
Where your own landscape has its own separation model — a sandbox, quality or pre-production system — the integration approach is aligned to it as part of scoping.
Every enterprise buyer has its own security requirements, and they differ enough that a generic page cannot satisfy them. Rather than guess at yours, we work through your assessment.
The output is documentation your security and procurement teams can act on — specific to your deployment, and therefore something we can stand behind.
We do not publish certification claims on this page. Where certification or formal attestation is part of your vendor assessment, ask us directly and we will answer precisely about what exists, what is in progress and what does not exist. We would rather give you a verifiable answer than a badge you cannot rely on.
We do not publish a hosting region here, because the answer belongs to a specific deployment rather than to a marketing page. Data location and residency requirements are addressed as part of the security assessment for your implementation.
Rather than state a standard we have not confirmed in writing for your deployment, we cover transport and storage protection concretely during the security review, so that your IT organisation gets an answer it can document.
We make no claims about test results or service levels on this page. These are contractual and assessment matters; raise them and they will be answered directly, in writing, as part of the commercial and security review.
Yes, and we expect it. Enterprise buyers normally run a vendor assessment covering architecture, access, data handling, sub-processors and incident process. We would rather work through your questionnaire than pre-empt it with generic statements.
Invoice documents can contain personal data such as contact names. The applicable data-protection terms, including a DPA where required, are agreed as part of the contract — our privacy terms are set out on the privacy page.
Send your security questionnaire or tell us what your review requires, and we will respond with documentation specific to your deployment — including a DPA where one is needed.