Integrate Atlar into your ERP

An ERP integration with Atlar can be done entirely through our API, meaning you can integrate with any ERP, data warehouse, or custom finance system. This approach offers the same functionality as our packaged ERP integrations (such as Business Central, NetSuite, or SAP).

👍

Building together:

Atlar will support you in all integration efforts with direct connections to the engineering team during and after the implementation to ensure smooth operations.

This guide covers the two main integration flows:

• Reporting into ERP — getting bank data into your ERP for visibility and reconciliation.
• Making payments from ERP — initiating payments from your ERP through Atlar.

Quick Decision Guide

Most integrations should use Atlar camt.053 for reporting and Payments API for payments. This combination gives you standardized formats, full payment visibility, and automatic reconciliation with your externalId.

Reconciliation Compatibility

The combination of reporting and payment method determines whether automatic reconciliation is possible:

⚠️

Avoid: Raw pain.001 upload (unless you have no alternative)

While reconciliation works with any reporting method, uploading raw pain.001 files means Atlar has no visibility into your individual payments. You bypass all payment features: approval workflows, audit trails, status tracking, analytics, and automatic statement enrichment. Only use this if you must preserve an existing pain.001 workflow.

Pre-requisite Setup

Before integrating, complete the following setup steps in Atlar:

1. Create a Role for Integration
   Define a role in your ERP or integration middleware with the required permissions.
   For detailed guidance, see Create an integration role.

2. Create a Programmatic Access User
   Create a dedicated user with programmatic access and API credentials.
   Refer to Programmatic user setup for step-by-step instructions.

3. Store the User's Credentials in Your ERP
   Save the access credentials securely within your ERP's integration configuration.
   These credentials will be used for all API calls to Atlar.

Reporting into ERP

There are three different ways to get bank reporting data into your ERP. Each option has different characteristics and is suited for different use cases.

Option 1: Atlar-generated camt.053 Bank Statements

Retrieve bank statements in a standardized ISO 20022 camt.053 format, generated by Atlar.

What it is:

• Atlar converts bank statement data into a standardized camt.053 XML format, regardless of the original format from the bank.
• Atlar enriches the statement with payment identifiers, linking bank transactions back to your original payments.

When to use this option:

• Your ERP has a camt.053 import capability.
• You want a consistent format across all banks, regardless of what format each bank provides.
• You need to reconcile payments automatically using your own payment's externalId or Atlar's payment identifiers.

Key benefits:

• Standardized format — Same XML structure regardless of which bank the statement came from.
• Payment identifiers included — Atlar adds proprietary references linking transactions to your payments:
  • atlar.credit_transfers.id — Atlar's payment ID
  • atlar.credit_transfers.externalId — Your external ID (if you provided it when creating the payment)
• Multiple camt.053 versions — Supports camt.053.001.02, .03, .04, and .08.

API Endpoints:

GET /connections/{cid}/reports/{id}/content?format=application/vnd.iso20022.camt.053.001.03+xml
GET /connections/{cid}/reports/{rid}/bank-statements/{id}/content?format=application/vnd.iso20022.camt.053.001.03+xml
GET /connections/{cid}/reports/-/content:bulk?format=application/vnd.iso20022.camt.053.001.03+xml

Available format values:

• application/vnd.iso20022.camt.053.001.02+xml
• application/vnd.iso20022.camt.053.001.03+xml
• application/vnd.iso20022.camt.053.001.04+xml
• application/vnd.iso20022.camt.053.001.08+xml

Reconciliation with externalId

When you create payments via the Payments API, you can include an externalId — your own identifier for the payment (e.g., invoice number, ERP payment ID).

In the Atlar-generated camt.053, this appears as a proprietary reference:

<Prtry>
    <Tp>atlar.credit_transfers.externalId</Tp>
    <Ref>your-external-id</Ref>
</Prtry>

If your ERP cannot read proprietary references, use the externalIdAsEndToEndId=true query parameter. This remaps your externalId to the standard EndToEndId XML element:

GET /reports/{id}/content?format=...&externalIdAsEndToEndId=true

With this option:

• Your externalId appears in <EndToEndId>your-external-id</EndToEndId>
• The original EndToEndId is preserved in a proprietary reference <Tp>EndToEndId</Tp>

Option 2: Financial Data API (Accounts, Balances, Transactions)

Retrieve structured account data, balances, and transactions via Atlar's Financial Data API.

What it is:

• Programmatic access to accounts, balances, and transactions as structured JSON data.
• Data is normalized, validated, and enriched by Atlar.

When to use this option:

• You prefer working with JSON over XML.
• You want Atlar-enriched data (e.g., transaction categories, attached payments).
• You're building a custom integration and want the easiest data format to work with.

Key benefits:

• Easier to parse — JSON is simpler to handle than XML in most programming environments.
• Validated data — Atlar verifies the data before exposing it. Sometimes banks report incorrect data (e.g., transaction sums don't match balance differences). Atlar flags these issues and works with banks to correct them before the data reaches your accounting systems.
• Enriched data — Includes Atlar-specific enrichments like transaction categories and links to Atlar payments.
• Payment identifiers — Support for externalId on transactions coming soon.

API Endpoints:

GET /financial-data/v2/accounts
GET /financial-data/v2/accounts/{accountId}/balances
GET /financial-data/v2/accounts/{accountId}/transactions

See the Accounts API reference for detailed request and response examples.

Option 3: Raw Bank Statements (Last Resort)

Retrieve the original bank statements as received from the bank, in their native format.

⚠️

Consider this option only if you have existing workflows that are already tuned to raw bank statement formats and you cannot change them. For most integrations, Option 1 (Atlar camt.053) or Option 2 (Financial Data API) provide better reconciliation capabilities.

What it is:

• The unmodified bank statement file exactly as received from the bank.
• Formats vary by bank: MT940, camt.053, CSV, NACHA (US), or proprietary API formats that aren't standardized.

When to use this option:

• You already have bank reconciliation processes/tooling tuned to the raw bank statement format from your banks.
• You don't plan to change or add new banks in the near term.
• You're not using Atlar's Payments API (you either pay directly with the bank or upload raw pain.001 files).

Limitations:

• Only identifiers the bank knows about will be present.
• Format varies per bank, so your ERP must handle multiple formats if you have multiple banks.

💡

Planning to use the Payments API? Your externalId will not appear in raw bank statements — see Reconciliation Compatibility above. Use Atlar camt.053 or the Financial Data API instead.

API Endpoints:

GET /connections
GET /connections/{connectionId}/reports
GET /connections/{connectionId}/reports/{reportId}/bank-statement

Making Payments from ERP

There are two ways to initiate payments from your ERP through Atlar.

Option 1: Payments API (Credit Transfers)

Submit payments programmatically using Atlar's Credit Transfers API.

What it is:

• Create payment batches using structured JSON or CSV requests.
• Atlar handles conversion to bank-specific formats.

When to use this option:

• You want full visibility into payments within Atlar (status tracking, reporting, analytics).
• You want Atlar to enrich bank statements with your payment identifiers (externalId).
• You want Atlar to handle bank-specific payment format conversion.

Key benefits:

• Full payment tracking — See payment status, results, and history in Atlar.
• Statement enrichment — Your externalId appears in Atlar-generated camt.053 for easy reconciliation.
• Bank format abstraction — Atlar converts your JSON request to the correct bank format (pain.001, etc.).

API Endpoints:

POST /payments/v2beta/credit-transfer-batches
GET /payments/v2beta/credit-transfer-batches/{batchId}/results

See the Credit Transfers API reference and Batch Payments document for detailed request parameters and examples.

Account Mapping

Each credit transfer references a source and a destination:

Source account — the source is always one of your internal Atlar accounts.
Your ERP must store the corresponding Atlar account ID on its representation of the bank account used to fund payments.

Destination account — the destination can be provided in one of two ways:

• An Atlar counterparty account ID, or
• An inline destination, where the beneficiary's bank details are provided directly in the request (e.g., IBAN, BIC, account number).

In your ERP's representation of a counterparty (for example, a vendor), you must store either:

• the Atlar counterparty account ID, or
• the full set of required bank details.

Option 2: Raw pain.001 Upload

Upload ISO 20022 pain.001 payment files directly.

What it is:

• Forward a pain.001 file you've generated (from your ERP, payroll system, or other vendor) directly to the bank.
• Atlar does not modify the file content — it's forwarded to the bank as-is.

When to use this option:

• You generate pain.001 files from your own system or another vendor's system (e.g., payroll).
• You need full control over the payment file content.

Important trade-offs:

⚠️

No Atlar payment features: When uploading raw pain.001 files, Atlar acts purely as a pass-through. The underlying payments are not visible in Atlar — only the file itself.

This means you will not have access to:

• Individual payment tracking or status in Atlar
• Approval workflows and authorization controls
• Audit trails for individual payments
• Payment analytics and reporting
• Automatic enrichment of bank statements with payment identifiers

Additionally:

• You must produce bank-specific formats — Atlar only forwards the file as-is. You are responsible for generating pain.001 files that meet each bank's specific requirements.
• You handle errors yourself — If payments fail or are rejected by the bank, you must interpret and handle those errors in your own systems.

Use this option only if you need to preserve existing pain.001 workflows and accept these limitations.

Identifier handling:

• Fully controlled by you. Whatever identifiers (End-to-End ID, etc.) you put in the pain.001 file will be forwarded to the bank.
• If the bank supports it, those identifiers will appear in the bank statement.

API Endpoints:

POST /connectivity/v2beta/connections/{connectionId}/instructions