NEXERA CoreSecurity
Access, money and data. Under control.
NEXERA Core protects three things: who has access, what happens with money and where your data is stored. Below, you can read how each of these is arranged in the core.
Only the right people, and only what their role allows.
Signing in runs through a managed identity provider with mandatory two-step verification. What someone may do after that is decided by NEXERA Core itself, again on every request.
- Two-step verification mandatory for everyone
- By invitation from an administrator only; nobody can create an account themselves
- A new account starts as read-only until an administrator assigns a role
- The role is checked on the server with every request; a modified token grants no extra permissions
- A disabled account loses access at the next request
- On a shared computer, the next user never sees the previous user's data
Every user has one role. It is assigned by an administrator, never by the user.
Everything, including settings, users and configuration.
All financial records, plus view access elsewhere.
Contacts, orders and items; can also read the payment reminder list.
Items and their data.
Stock, shipments and packing.
Production orders and recipes.
Quality checks and release from quarantine.
Price books of the item configurator; otherwise view only.
The telephone agent: answering questions from the core, within fixed limits.
View only, no changes. The starting point for every new account.
The shared screen on the shop floor, limited to a fixed list.
A second pair of eyes where money is involved.
With payments and changed bank details, the damage from an error or fraud is greatest. That is where NEXERA Core has its strictest controls.
- Approval by a second person for issuing, sending and paying, and for changed supplier bank details
- An approval applies to exactly the content that was approved; if anything changes afterwards, a new approval is needed
- Whoever submits a request cannot approve it themselves
- Payment orders are recorded before they go to the bank; if the bank status is uncertain, nothing is resent automatically
- A payment only counts as paid once it has been reconciled
- Consecutive invoice numbers per legal entity, and postings that always balance
- Closed periods and financial years can no longer be changed
Where your data is stored, by type of data.
The location of each type of data and how it is protected, including what is processed outside the EU.
Database and financial records
A separate database for each customer, on a hosting platform in the EU.
Documents and files
Stored encrypted and accessible only through temporary, signed links.
Back-ups
A second copy outside the hosting platform, also in the EU.
AI questions (optional)
If LIV is switched on, only the figures needed for each question go to the language model, in a European cloud region.
Signing in
With the identity provider, under the EU-US Data Privacy Framework and standard contractual clauses. Passwords and MFA keys never enter NEXERA Core.
AI telephony and reading aloud (optional)
Speech is processed in real time in the US: by xAI for AI telephony, and by a separate speech service for reading aloud. Call transcripts and summaries are kept in your own environment in the EU.
Recoverable, and tested in advance.
A back-up is only worth something if the restore works. That is why we test the restore before you go live.
- Back-ups in two layers: the platform's managed back-ups for quick recovery, and a daily copy outside the platform for the long term
- A restore test before go-live: restore, start up and check a known invoice
- Three separate environments: development, test and production
- Error reports and logs are collected centrally, so that we spot problems quickly and can trace them
- Scheduled tasks never do anything twice on a second run; a missed run is picked up the next time
Secure development
Every change
along the same route.
From idea to production, without exceptions.
The financial core was written test-first: the calculations for VAT, postings and the XAF audit file existed and had been tested before there was a screen.
Small and well defined, stating what changes and why.
Automated code scans, an AI review and human reviewers. Every finding is resolved or recorded.
The full test run must pass, including the tests against a real database.
Deployed and checked in the development environment.
Reviewed in a separate environment before it moves on.
Only after a deliberate, manual approval.
Everything your IT team wants to know, in writing.
We set out the details for your IT department and data protection officer. If your organisation has its own security questionnaire, please send it along and we will go through it together.
We send it within two working days.
The database, documents and back-ups are stored in the EU. Signing in runs through an identity provider in the US, under the EU-US Data Privacy Framework and standard contractual clauses; passwords and MFA keys never enter NEXERA Core. If LIV is switched on, only the figures needed for each question go to the language model, in a European cloud region.
An administrator disables the account. Access ends at the next request, and that user's history in the audit trail is retained.
Changed bank details of a supplier only become a payment destination after approval by a second person. Payment runs consist only of approved invoices, and an approval lapses as soon as the content changes.
Yes. You set approval rules for each action, such as issuing, sending or paying. A request that is left waiting escalates after the set time.
The financial records are set up for the statutory retention period of seven years. The XAF audit file for a financial year can be regenerated throughout that period.
NEXERA Core
Discuss security with the people who build it.
Bring your IT team or data protection officer. We show how access, approvals and back-ups work in practice.