Skip to main content
POST
Match a payout to a deposit

Authorizations

Authorization
string
header
required

API key issued per entity via Settings > Developers > API Keys. Each key carries scopes (e.g. orders:read, products:write). Bearer token format: Authorization: Bearer ark_live_ent_Test keys use ark_test_ent_. Both are issued per entity
via Settings > Developers > API Keys.

Headers

Idempotency-Key
string

Deduplicates retried match submissions for 24 hours.

Maximum string length: 255

Path Parameters

entity_id
string<uuid>
required

Body

application/json
bank_transaction_id
string<uuid>
required

The inbound bank transaction to match.

marketplace_payout_id
string<uuid>
required

The unmatched, posted marketplace payout to pair with it.

reconciliation_id
string<uuid> | null

Optional open bank-reconciliation to attach the match to.

skip_settlement_correction
boolean
default:false

Record the match without correcting the journal entry when the payout settles a different bank account than the transaction. The match still succeeds and the bank side still ties; the general-ledger side stays on the account it is on. The choice is recorded on the audit trail for the match.

Response

Match recorded. A settlement correction is posted only when the payout settles a different bank account than the matched transaction and skip_settlement_correction was not sent; settlement_correction.status says which happened.

bank_transaction_id
string<uuid>
marketplace_payout_id
string<uuid>
platform
string
matched
boolean
amount_warning
string | null

Set when bank and payout amounts differ by more than $0.05.

bank_account_warning
string | null

A plain sentence for the operator when the payout settles a different bank account, saying what was done about it. Null when the banks agree or the payout's bank cannot be attributed.

bank_account_scope
enum<string>

Whether the payout's journal entry settles the same bank as the matched transaction. unknown_bank_account means the entry has no single bank leg to compare, which is not a mismatch.

Available options:
same_bank_account,
different_bank_account,
unknown_bank_account
settlement_correction
object

What happened to the GENERAL LEDGER when you matched a connector deposit to a bank line. Added 2026-09-19 by BANKFEED wave 4 lane W4-F2.

A processor states which bank account it paid, on every payout. Arcus used to book every payout to one bank account configured per platform, so when the settlement bank changed, deposits kept landing on the old account in the books while the cash landed in the new one at the bank. Matching the deposit to the real bank line is the moment Arcus learns the truth, and this object says what it did with it.

status is the field to switch on:

  • posted a correction was written. shape says which.
  • not_applicable the banks already agree, or the payout has no single bank leg to compare.
  • not_needed right bank, right day: there is nothing to correct.
  • pending_operator_review the payout settles a different bank, but this match was automatic or part of a bulk approve, and Arcus never moves money in the ledger without a person asking. Open the payout and match it yourself to correct the books.
  • skipped_by_operator you asked for the match without the correction.
  • not_resolvable the payout, one of the two banks, or the date to post on could not be resolved. reason says which: payout_has_no_journal_entry, settle_bank_gl_unresolved, target_bank_gl_unresolved, or bank_line_has_no_date when the bank line being matched carries no date to post the correction on. Nothing is posted and the match itself still succeeds.
  • entry_not_live the payout's journal entry is voided or reversed.

shape says how the correction was written:

  • reclass_only one entry, dated on the payout date, moving the deposit from the bank it was booked to onto the bank it was paid into.
  • redate_and_reclass the payout entry was ALSO dated in a later month than the day the money arrived, so the correction is a dated pair: one entry removes the deposit from the month it was wrongly booked in, the other records it in the month it arrived. Each month closes on the truth, and the clearing account carries the money in between, which is where it genuinely was.
  • redate_only the bank was right and only the month was wrong.

The ledger effect of any shape is zero: every entry balances, and the trial balance is the same to the cent before and after. What moves is which bank account, and which month, holds the deposit.

settlement_mapping
object | null

Set when this match taught Arcus which bank account a processor destination pays into, so later payouts from the same destination book to the right bank without anyone configuring it. Learned only from an explicit match by a named user.

book_side
object | null

What the GENERAL LEDGER now says about the money this bank line explains. Added 2026-09-19 by BANKFEED wave 4 lane W4-G, and it is purely additive: no request field changed and no existing response field changed meaning.

A bank reconciliation has two sides. The bank side is reconciliation_status on the bank transaction. The BOOK side is reconciled_at on the journal entry's line on that bank account's GL account, and until this lane no verb outside a statement session ever wrote it, so matched money could read UNCLEARED in the ledger forever.

STILL NO GL IS POSTED. The stamp writes no debit and no credit; the trial balance is identical before and after, and a closed period cannot be moved by it. What it changes is which lines the reconciliation workbench and the bank register's open-items tile still treat as outstanding.

stamped: 0 with a reason is an honest answer, not an error: no_leg_on_bank_gl means the entry carries no line on THIS account's GL (a payout settled to a different account, for example); already_reconciled means a session or a baseline had already cleared it; missing_argument means the record carries no journal entry to stamp.

correction_book_side
object[]

The settlement-correction entries whose bank line was marked cleared by this match, so the cleared balance follows the correction rather than staying on the original entry.