Incoming Transactions
Incoming transactions represent actual payments received. They are matched against expected transactions by LedgerMatch. Create them manually, sync from Stripe or SFTP, upload via CSV, or import via EBICS.
What are incoming transactions
Incoming transactions are payments you have actually received. They are the "actual" side of reconciliation—the counterpart to expected transactions (payments you anticipate). Each incoming transaction starts as PENDING and is matched against expected transactions by LedgerMatch. Once a match is accepted, its status becomes MATCHED; if no match is found or all are rejected, it becomes UNMATCHED.
Amount and direction — Amounts are stored as non-negative numbers. Whether a line is a debit or credit is stored separately as direction (DEBIT or CREDIT). Bank imports (e.g. EBICS/CAMT) set this from statement indicators; manual/API calls may omit direction and default to CREDIT, or send a negative amount which the API normalizes to a positive amount plus DEBIT.
How incoming transactions are created
| Source | How they enter | Notes |
|---|---|---|
| manual | POST /incoming-transactions with full fields | You supply merchant, amount, currency, date, description |
| stripe | Stripe sync job or webhook | Field mappings transform Stripe charge data |
| csv | POST /incoming-transactions/upload | Bulk upload against a CSV data source connection; field mappings map CSV columns |
| ebics | Bank sync (EBICS) | Imported from bank statements |
| sftp | SFTP sync (POST /data-sources/sftp/sync) | CSV files on a remote server; field mappings or CSV-style defaults |
For manual, you provide all required fields directly. For stripe, csv, ebics, and sftp, you configure field mappings to map source data (e.g. Stripe charge fields, CSV columns, SFTP row payloads) to the standard incoming transaction schema. See Data Sources for setting up Stripe, EBICS, and SFTP connections.
What happens when an incoming transaction arrives
- Created — Transaction is stored with status
PENDING. - Matching — If
autoMatchEnabledis true, LedgerMatch is called immediately to find candidate expected transactions. Otherwise, matching runs via a scheduled job or manual trigger. - Resolved — When a match is accepted, the incoming transaction becomes
MATCHED. If no match is found or all are rejected, it becomesUNMATCHED.
See Matches for how matches work and Match Flow for the full flow.
Status lifecycle
| Status | Meaning |
|---|---|
| PENDING | Awaiting match or match resolution |
| MATCHED | Linked to an expected transaction (match accepted) |
| UNMATCHED | No match found or all matches rejected |
Field mappings for non-manual sources
When creating from Stripe, CSV, EBICS, or SFTP, you send rawData (the source payload) instead of individual fields. Field mappings define how to extract merchant, amount, date, reference, and description from that payload; you can also map direction when the source provides it. Configure mappings per source in Field Mappings. If no mapping exists for a source, creation may still succeed where a built-in default applies (e.g. Stripe charges, CSV rows, EBICS CAMT parsers, SFTP CSV rows).
API Reference
For attributes, endpoints, parameters, and request/response samples, see Incoming Transactions in the API Reference.