Skip to main content
This guide covers how to import transaction data from external sources into Matcher for reconciliation.

Supported formats


Matcher accepts transaction files in three formats:
  • CSV: Comma-separated values with headers. Most common for bank exports.
  • JSON: Array of transaction objects. Best for API integrations.
  • XML: Structured elements. Common for enterprise systems.

File structure requirements


Each file must contain transaction records with fields that can be mapped to Matcher’s internal schema.

Required fields

Every transaction must have these fields (or mappable equivalents):

Optional fields

Format examples


CSV

CSV Requirements:
  • First row must be column headers
  • UTF-8 encoding
  • Comma delimiter (configurable)
  • Quote fields containing commas or newlines
Code example

JSON

JSON Requirements:
  • Root element must be an array
  • Consistent field names across objects
  • UTF-8 encoding
Code example

XML

XML Requirements:
  • Valid XML with declaration
  • Root element containing transaction elements
  • UTF-8 encoding
Code example

Upload via API


Use the import endpoint to upload transaction files.

Preview before uploading

Before committing a file for ingestion, you can preview it to verify column detection and sample data. This helps catch field mapping issues early.
cURL

Response

API Reference: Preview file

Single file upload

cURL
Send the format field before the file part. If file arrives first, the format is inferred from the filename extension (.csv/.json/.xml). Upload returns 202 Accepted with the created job.
API Reference: Upload file

Response

Check import status

cURL
API Reference: Get import status

Response (Processing)

Response (Completed)

Per-row parse/normalization errors are not embedded in the job. When completedWithErrors is true (or the job FAILED), fetch the details from GET /v1/imports/contexts/{contextId}/jobs/{jobId}/errors (capped at 100 stored rows, with totalErrors/truncated accounting). For a wholesale FAILED job, diagnosis carries a safe one-line reason.

Import job status values

Validation and error handling


Matcher validates uploaded files at multiple stages.

Validation stages

1

Format Validation

Verifies the file is valid CSV, JSON, or XML with correct structure.
2

Schema Validation

Checks that required fields are present and match the configured field map.
3

Data Type Validation

Validates amounts are valid decimals, dates are parseable, currencies are valid ISO codes.
4

Business Rule Validation

Applies context-specific rules like date ranges, amount limits, etc.

Common validation errors

Handling errors

By default, valid rows are imported even if some rows have errors. Configure error handling behavior through context settings or handle errors after import completion by reviewing the job status response.

Duplicate detection


Matcher automatically detects and handles duplicate transactions to prevent double-counting.

How duplicates are detected

Duplicates are identified by the row’s dedup key within a source:
  • source_id
  • external_id (the source-system transaction identifier)
If a row repeats that key—within the same upload or against already-persisted data—it is treated as a duplicate.

Duplicate handling options

Set the duplicate_policy key in the source config to control handling: When the key is absent, KEEP_FIRST applies.

Viewing duplicate details

The import summary shows how many duplicates were found:

Batch uploads


For large reconciliation jobs, you can upload multiple files in sequence.

Upload multiple files

Wait for all imports

Before running matching, ensure all imports are complete:

Search uploaded transactions


After importing files, you can search across all transactions in a context to verify data quality or investigate specific records.
cURL

Response

API Reference: Search transactions
Supported filters include amount_min, amount_max, date_from, date_to, currency, source_id, status, and free-text search via the q parameter.

Best practices


Check file format and encoding locally before uploading. This catches obvious errors faster.
Standardize on ISO 8601 format (YYYY-MM-DD or YYYY-MM-DDTHH:MM:SSZ) across all sources to avoid parsing issues.
Always include unique transaction IDs from the source system. This enables proper duplicate detection and audit trails.
Decide on a convention (negative for debits, positive for credits) and apply it consistently. Document this in your field mapping.
For very large files (>50MB), consider splitting into smaller chunks by date range. This improves reliability and allows partial retries.
For recurring reconciliation, automate file uploads using scheduled jobs or webhooks from source systems.

Next steps


Reviewing Matches

Learn how to interpret match results and confidence scores.

Field Mapping

Configure how source fields map to Matcher’s schema.