Service Description

1Outbound payments

• Canonical input: you submit payment instructions in one bank-neutral JSON format (the canonical format, specified in the Documentation), via the API or the web portal. Amounts are given as exact decimal values, and totals are calculated without rounding errors.
• Three-level validation: every instruction is validated against (1) generic rules that apply to any payment, (2) the chosen bank's specific rules, and (3) rules for the declared payment type. Validation reports all issues in a single response, each with a stable machine-readable code, the field path, and a plain-language message.
• Conversion: valid instructions are converted to the target bank's ISO 20022 payment-file format (pain.001), following that bank's implementation guidelines; generated files are validated against the official ISO 20022 schemas.
• Approval: release requires approval under your configured approval policy (single, dual, or customised: amount limits, separation of duties, ordered tiers). Approval policies are versioned; changes are subject to the controls described in the Documentation.
• Delivery: approved files are delivered by us directly to the bank over your active bank connection. Signed payment files are not returned to you or any third party, unless the Documentation describes otherwise.
• Duplicate protection: idempotency keys guard against double submission (retention: 24 hours).

2Bank connectivity channels

Connections are established per company, per bank, under your own bank agreement, in test or production environment (a bank may have both). Supported channel families:

Setup is guided in the portal, including key/certificate generation and bank-side enrolment steps. Bank onboarding timelines depend on the bank.

3Inbound reporting

• Statements: camt.053 and legacy MT940 statements are retrieved over your bank connections (or uploaded manually) and normalised into one structured format across all banks.
• Payment status: bank acknowledgements (pain.002) are ingested and matched to your payments, which updates each payment's status (imported, converted, sent, validated, executed, or rejected, partially accepted or cancelled).
• Reconciliation events are exposed in the portal, via the API, and via webhooks.

4Platform features

• Web portal: dashboard with go-live readiness, manual conversion, test payments, bank setup wizards, journals of payments sent and statements imported, approvals, users and roles, activity log, settings.
• API: JSON over HTTPS with a stable error contract (machine-readable codes), cursor pagination, and OpenAPI documentation.
• Webhooks: HMAC-signed event delivery with retries and stable event ids.
• Journal and audit: retained normalised documents; a per-company, hash-chained, verifiable activity log.
• Account structure: platform, company and user levels, with roles (admin, approver, viewer) and a workspace administrator level; white-label branding on platform arrangements.
• Email invitations for user onboarding.
• ERP Add-ons: software that connects your ERP system to the Services, as described in Section 5.

5ERP Add-ons

• What an ERP Add-on is: an ERP Add-on is software we provide that runs in your ERP system or other systems and connects them to the Services. The ERP Add-on currently offered is the BankConnector add-on for Uniconta. ERP Add-ons are part of the Services and give access to them in the same way as the web portal and the API.
• Right to use: ERP Add-ons are licensed, not sold. You may use an ERP Add-on during the term, only in the companies in your ERP system for which we have enabled it, and only together with the Services. The terms of that right, including the restrictions on copying, modifying and reverse engineering, are set out in the Agreement (in the Customer Agreement, Sections 14.1 and 14.4).
• Delivery: we deliver an ERP Add-on either through the ERP vendor's own distribution (for Uniconta, as a plugin that we share with each company in Uniconta for which it is enabled) or as a file that you install as described in the Documentation. We stop delivering an ERP Add-on to you when the Agreement ends.
• Updates: we may update an ERP Add-on at any time, for example to correct errors, to follow changes in the ERP system or the Services, or for security reasons. An update delivered through the ERP vendor's distribution reaches you the next time the ERP client starts; an update delivered as a file is installed by you. We may require an update to be installed for an ERP Add-on to continue to work with the Services.
• Your ERP system: your ERP system, its vendor and the data in it are not part of the Services. We are not responsible for the availability of the ERP system, for changes made by the ERP vendor that affect an ERP Add-on, or for postings, settings or data that you or your users enter in the ERP system. We make reasonable efforts to adapt ERP Add-ons to new versions of the ERP system.
• Payments are sent by a user: an ERP Add-on sends a payment to the Services only when one of your users chooses to send it, and the approval policy configured in the Services applies to that payment as to any other payment. Automatic posting in the ERP system takes place only if you have switched it on.
• Data: personal data that an ERP Add-on sends to the Services (such as supplier names, addresses and bank account details) is Customer Data and is processed under the Data Processing Agreement. Data that an ERP Add-on keeps in your ERP system or on your computers (such as payment status, a copy of the activity log, the connection to the Services and a support log) is held in your own systems, as described in the ERP Add-on's installation guide.

6Environments and Limited Releases

• Production: live bank endpoints and payments with real funds, protected by the measures in the Security Policy.
• Sandbox: a separate environment with test bank endpoints and demonstration scenarios, in which no real payments are made. Sandbox is available for the full term but is a Limited Release (no SLA/support commitments).
• Limited Releases: sandbox, betas, pilot bank integrations, and features marked preview/beta/early access, provided as-is, per the Agreement.

7Data retention schedule

Company-level and per-user GDPR erasure functions are built in and also reach the archive. A legal hold pauses deletion until it is lifted. Backups expire on their normal cycle. Export of journal and documents is available self-service throughout the term.

8Service boundaries

• We do not hold, receive or transmit funds; payment execution is performed by your bank under your own bank agreement and mandates.
• We do not guarantee that a bank will accept or process any file; validation reduces but cannot eliminate rejections.
• The Services may flag payment parties resembling entries on public sanctions lists. Such flags are advisory only, may be incomplete or wrong, and are not a compliance service. We do not perform KYC/AML on counterparties or monitor transactions for financial-crime purposes.
• Bank onboarding, bank fees and bank-side configuration are matters between you and your bank.