Data Processing Notice

1. About This Notice

This Data Processing Notice explains how Al Sannad processes information when an organisation uses the Al Sannad UAE e-invoicing platform.

Al Sannad is provided by Nexain Arabia FZC LLC.

This notice complements:

• the Al Sannad Privacy Policy;
• the applicable customer agreement;
• any data-processing agreement or schedule; and
• the customer's own privacy and compliance obligations.

Where a signed customer agreement contains different or more specific terms, the signed agreement applies to that customer relationship.

2. Processing Roles

Depending on the activity:

Customer Organisation

The customer organisation generally determines:

• which invoice information is submitted;
• which parties are included;
• the tax and accounting treatment;
• which users receive access;
• the business purpose of processing; and
• how invoice information is created in its ERP or accounting system.

For customer invoice data, the customer normally acts as the organisation responsible for determining the purpose and content of the processing.

Nexain Arabia FZC LLC and Al Sannad

Nexain Arabia FZC LLC processes customer information through Al Sannad to provide the contracted e-invoicing service.

This may include:

• receiving invoice records;
• validating invoice structures;
• exchanging invoices;
• receiving invoices;
• reporting eligible transactions;
• retaining transaction evidence;
• providing operational support; and
• protecting the platform.

The final controller and processor terminology must follow the executed customer contract and applicable law.

3. Categories of Information Processed

Invoice and Credit-Note Data

• invoice identifiers;
• issue dates;
• invoice and credit-note types;
• line descriptions;
• quantities;
• prices;
• allowances and charges;
• tax categories and rates;
• taxable amounts;
• VAT amounts;
• totals;
• payment information;
• order and contract references;
• preceding invoice references; and
• other required PINT-AE or UBL fields.

Business-Party Data

• supplier name;
• buyer name;
• legal entity details;
• business address;
• tax-registration number;
• Peppol participant identifier;
• contact information included in the invoice; and
• business references.

User and Access Data

• authorised-user identity;
• role;
• authentication events;
• MFA status;
• permissions;
• account activity; and
• administrative actions.

Transaction and Evidence Data

• validation outcomes;
• failed rules;
• submission attempts;
• exchange records;
• delivery responses;
• UAE DCTCE reporting records;
• correlation IDs;
• timestamps;
• reconciliation outcomes; and
• audit and operational evidence.

Integration Data

• source-system identifiers;
• ERP connection details;
• API requests;
• webhook events;
• file-upload records;
• batch-processing information; and
• connector diagnostics.

Technical and Security Data

• IP address;
• service logs;
• device or session information;
• authentication logs;
• certificate activity;
• security events;
• monitoring events; and
• incident records.

4. Sources of Information

Information may be received from:

• SAP S/4HANA;
• SAP ECC;
• SAP Business One;
• Oracle Fusion;
• Oracle NetSuite;
• Oracle E-Business Suite;
• REST APIs;
• Excel or batch uploads;
• webhooks;
• manual or portal entry;
• Peppol participants;
• connected Access Points;
• the Al Sannad SMP;
• customer users; and
• authorised platform personnel.

The documented connector scope includes six enterprise ERP connector kinds, plus Excel and REST API intake.

5. Purposes of Processing

Information is processed to:

• receive outbound invoice data;
• receive inbound electronic invoices;
• map source records into structured invoice formats;
• validate invoices against PINT-AE and UBL requirements;
• identify rule-level validation errors;
• discover recipient capabilities;
• transmit and receive documents through Peppol AS4;
• support UAE DCTCE reporting;
• connect reporting and delivery events to the invoice;
• preserve transaction evidence;
• support corrections and resubmission;
• reconcile expected and completed activity;
• provide reports and exports;
• administer customer users and permissions;
• protect tenant data;
• manage certificates and keys;
• monitor platform operation;
• investigate incidents; and
• provide contracted support.

6. PINT-AE and Validation Processing

Al Sannad processes invoice data against the applicable PINT-AE and UBL validation rules.

The documented platform includes:

• PINT-AE v1.0.4 validation;
• Saxon-based rule processing;
• UBL structural validation; and
• more than 1,300 active Schematron assertions.

Validation results may identify:

• the affected rule;
• the relevant invoice location;
• the validation outcome; and
• information requiring correction.

The files confirm that PINT-AE validation is implemented and supported by the documented validation service.

7. Peppol Exchange and Recipient Discovery

Al Sannad processes electronic invoices through Peppol AS4 exchange.

The documented platform implements:

• sender-side Access Point functionality;
• receiver-side Access Point functionality;
• an SMP for participant metadata;
• recipient discovery; and
• delivery responses.

Recipient and endpoint information may be processed to determine whether a participant supports the required electronic document type.

The files confirm Peppol AS4 and SMP capabilities. Any accreditation statement is limited to the verified status expressly published on this website.

8. UAE DCTCE Reporting

Al Sannad processes eligible transaction data through its UAE DCTCE reporting capability.

Reporting records may include:

• invoice identifiers;
• reporting status;
• target information;
• transmission events;
• reporting outcomes;
• incident information;
• readiness records; and
• related transaction evidence.

The files confirm implementation of the DCTCE C5 reporting model and the FTA status expressly published on this website. These statements do not change each customer's responsibility for invoice accuracy, tax treatment or legal obligations.

9. Evidence and Audit Records

Al Sannad creates and retains records relating to:

• invoice intake;
• validation;
• exchange;
• delivery;
• reporting;
• correction;
• resubmission;
• reconciliation;
• user activity; and
• sensitive administrative actions.

A correlation ID may connect the lifecycle of one transaction across multiple processing stages.

The documented evidence chain is append-only at the database level and uses database permissions and triggers to restrict deletion.

10. Tenant Isolation and Access Control

Customer data is separated through tenant-level controls.

Documented controls include:

• PostgreSQL row-level security;
• a CI gate that detects missing row-level protection;
• role-based access;
• multi-factor authentication;
• separate tenant records;
• controlled platform administration; and
• distinct Tenant and Super Admin environments.

Every tenant table is documented as protected by row-level security, with build checks intended to identify missing coverage.

11. Certificate and Key Processing

Al Sannad processes information required to operate certificates and encryption keys.

This may include:

• certificate identifiers;
• certificate status;
• expiry dates;
• rotation records;
• revocation records;
• approval records;
• counterparty validation results; and
• key-management configuration.

Sensitive certificate operations require two-person control with fresh MFA.

12. Storage and Retention

Every Al Sannad pricing plan includes a seven-year retention policy for invoice records and related transaction evidence.

Retention may apply to:

• invoice payloads;
• credit notes;
• validation outcomes;
• delivery responses;
• UAE reporting records;
• reconciliation records;
• operational evidence; and
• related audit records.

Information may be retained longer where required because of:

• legal obligations;
• contractual requirements;
• disputes;
• investigations;
• security incidents; or
• legal holds.

The sourcebook confirms seven-year retention across all plans.

13. Data Location

The approved commercial position is that Al Sannad is deployed by default to a UAE public-cloud region, with other deployment arrangements potentially available under enterprise terms.

The evidence files also warn that this must not be described as current production hosting until production infrastructure and the relevant cloud contract are confirmed.

The public website codebase does not contain a confirmed production hosting location for customer platform data. Production hosting statements should follow the signed customer agreement and confirmed deployment environment.

14. Security Measures

Documented Al Sannad controls include:

• row-level tenant isolation;
• role-based access;
• multi-factor authentication;
• controlled certificate operations;
• two-person approval;
• fresh MFA for sensitive actions;
• append-only evidence;
• write-once object storage;
• encryption and key-management controls;
• malware scanning;
• monitoring and disruption detection;
• PKI monitoring;
• specification-drift monitoring; and
• controlled audit records.

These controls are designed to reduce unauthorised access, loss, alteration and deletion. They do not create an unconditional guarantee that no security event can occur.

15. Subprocessors and Service Providers

Al Sannad may rely on service providers supporting:

• cloud infrastructure;
• email delivery;
• identity and authentication;
• object storage;
• monitoring;
• communications;
• customer support; and
• security operations.

The provided source files do not contain an approved production subprocessor register. Assumed or development-only providers are not published as production subprocessors.

16. International Transfers

Where a service provider processes information outside the UAE, Nexain Arabia will apply the contractual and organisational measures required for the relevant transfer.

Transfer language should reflect actual production providers, hosting location, support location, email-delivery location, monitoring location and customer contractual requirements.

17. Customer Responsibilities

Customers remain responsible for:

• ensuring invoice information is accurate;
• determining lawful processing purposes;
• assigning appropriate user access;
• protecting ERP credentials;
• applying correct tax treatment;
• maintaining internal approvals;
• responding to data-subject or regulatory requests where applicable;
• informing Nexain Arabia of required restrictions;
• avoiding unnecessary personal data in invoice fields; and
• using Al Sannad according to the signed agreement.

18. Data Requests, Correction and Deletion

Requests concerning customer invoice data should normally be directed first to the customer organisation that submitted or controls that data.

Nexain Arabia may assist a customer with:

• locating relevant records;
• correcting platform-held information where permitted;
• applying retention or legal-hold controls;
• exporting relevant records;
• restricting processing where supported; and
• deleting or returning data after contract termination where legally and contractually permitted.

Deletion may be limited where information must remain retained because of:

• UAE invoice-retention requirements;
• tax or accounting obligations;
• evidence preservation;
• security investigations;
• disputes; or
• legal hold.

19. Security Incidents

Where an incident affects customer information, Nexain Arabia will follow the incident-handling, investigation and notification obligations contained in:

• applicable law;
• the customer agreement;
• the data-processing agreement; and
• the relevant incident-response procedures.

The files support monitoring and disruption detection but do not define a public universal notification time. Do not add one unless it is contained in the final contractual or legal requirements.

20. Contract Termination

On termination of a customer agreement, customer information will be handled according to:

• the signed contract;
• the retention policy;
• applicable legal obligations;
• legal holds;
• agreed export or return arrangements; and
• deletion procedures supported by the platform.

The seven-year invoice-retention policy may continue to apply where records must be preserved.

21. Changes to This Notice

This notice may be updated when:

• processing activities change;
• new providers are introduced;
• platform capabilities change;
• hosting arrangements change;
• regulatory requirements change; or
• contractual terms are updated.

The current version will be published with its effective date and last-updated date.

22. Contact

Questions about this Data Processing Notice may be sent to: