System Status

Each functional area of the platform is tracked separately, because a fault in one area does not necessarily affect the others. Data isolation and posting integrity are enforced at the data layer, so an interface issue in one module does not change records owned by another.

These are the only three classifications used on this page:

• Operational: the component is available and behaving as designed. Isolated reports under investigation do not by themselves change this classification.
• Degraded: the component is reachable but impaired. Requests may be slower than normal, a secondary feature may be unavailable, or a background process may be delayed. Records already committed remain intact.
• Outage: the component is unavailable or is returning errors for a substantial share of requests, and the operations team is actively engaged on it.

There is deliberately no fourth classification for a partially known issue. A condition is either something we are prepared to state, or it belongs in the incident communication described below.

Routine platform updates are applied without interrupting service and require no action from you. Where a change genuinely requires a service interruption, the affected workspaces are notified in advance using the contact addresses on file for the tenant.

• Maintenance that could interrupt access is scheduled outside standard business hours where possible.
• Maintenance affecting financial posting is scheduled outside period-close windows where possible.
• This page is updated to reflect any window during which a component is expected to be unavailable.

When a confirmed incident affects availability or data processing, this page is updated with the affected components and their classification, and it continues to be updated until the issue is resolved.

• Incidents affecting a single tenant are communicated directly to that tenant rather than posted here.
• Incidents affecting multiple tenants or a shared component are reflected on this page.
• Once resolved, the component returns to Operational. Corrective work that continues after service is restored does not hold a component in an impaired classification.

Availability and durability are separate concerns, and an availability incident is not a data incident. Committed records, posted journal entries and stored documents are unaffected by a component being temporarily unreachable.

Financial operations that cannot complete safely are designed to fail rather than to record a partial result. An interrupted posting is therefore not written at all, instead of leaving an unbalanced or half-applied entry to be found later.

For the technical and organizational controls behind this, including encryption, access control and audit logging, see the Security and Compliance Overview.

If your experience does not match the condition shown on this page, contact the operations team at support@nexusend2end.com. Reports are triaged faster when they include the following:

• The affected page or module, and the specific action that failed.
• The approximate time the issue occurred, including your time zone.
• Any message shown on screen, quoted exactly.
• Whether the issue is reproducible or happened only once.

Signed-in users can also raise a ticket from Submit Ticket in the workspace sidebar, which attaches the workspace context automatically. That control requires an active session, so email remains the correct route if you cannot sign in.