Supported source types
Matcher supports four source types. Each represents a category of data origin:
| Type | Description | Typical use |
|---|---|---|
LEDGER | General ledger accounts | Internal accounting systems |
BANK | Bank statements | External bank feeds |
GATEWAY | Payment processor transactions | Payment gateways |
CUSTOM | Custom integrations | ERPs, card networks, or any other data source |
Ingestion methods
Transaction data is ingested through file upload:
| Method | Use Case | Formats |
|---|---|---|
| File Upload | Manual CSV/JSON/XML uploads | CSV, JSON, XML |
File-based ingestion
The most common method for bank statements and ERP exports.
Manual upload
Use the file upload endpoint to import transaction files manually.Bank connections
Standard Bank format
Most banks provide CSV or MT940 formatted statements:Mt940/mt942 format
For SWIFT-formatted bank statements:ERP and custom connections
Use the
CUSTOM source type for ERP systems (SAP, Oracle, NetSuite, etc.) and any other data source that doesn’t fit the BANK, LEDGER, or GATEWAY categories.
Example: ERP source
Payment processor connections
Stripe
Adyen
Card networks
For card network settlement files (Visa, Mastercard, Elo), use theCUSTOM source type:
Connection security
Credential storage
All credentials should be stored securely in an encrypted vault and referenced by ID in source configurations.Ip allowlisting
Configure IP allowlisting at the infrastructure level (load balancer, API gateway, or firewall) to restrict which IPs can push data to Matcher. Source entities do not have asettings.security configuration. Manage IP restrictions outside the application.
Webhook signatures
Matcher signs outbound webhook payloads with HMAC-SHA256. For inbound data, verify signatures at the infrastructure level before data reaches Matcher. Source entities do not have asettings.webhook configuration.
Data format requirements
Required fields
Every transaction must include:| Field | Type | Description |
|---|---|---|
transaction_id | String | Unique ID from source |
amount | Decimal | Transaction amount |
currency | String | ISO 4217 code |
date | Date | Transaction date |
Recommended fields
| Field | Type | Description |
|---|---|---|
reference | String | Payment reference |
counterparty | String | Other party name |
type | String | credit/debit |
posting_date | Date | Settlement date |
Field mapping
Use a dedicated endpoint to manage field mappings, not the source’sconfig object. Create field mappings for a source using:
cURL
Best practices
Validate files before uploading
Validate files before uploading
Check that uploaded files contain the required fields (transaction_id, amount, currency, date) before uploading. This prevents ingestion errors.
Use consistent file formats
Use consistent file formats
Standardize on a single format (CSV, JSON, or XML) per source to simplify field mapping and reduce errors.
Secure credentials properly
Secure credentials properly
Store all API keys and passwords in the vault. Never include credentials in configuration payloads.
Test with sample data first
Test with sample data first
Validate field mapping and data quality with sample files before uploading production data.

