> ## Documentation Index
> Fetch the complete documentation index at: https://docs.arcuserp.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Link a bank line to the transfer journal entry that already booked it
> Required API key scope: `accounting:write`
Links an unreconciled bank feed line to an EXISTING bank-transfer
journal entry and **posts nothing**.
**The problem it solves.** Banks post the two legs of one internal
transfer on different days. When the first leg is recorded as a transfer
and the second arrives afterwards, the second leg has no twin to be
matched against (the first is already `matched`), so the only other verb
available records a SECOND transfer entry for the same money -- one bank
GL permanently overstated, the other understated. This endpoint is the
alternative: the movement is already on the books, so the line is
attached to the entry that booked it.
**The server re-validates, and the caller cannot steer it.** The
`journal_entry_id` must still satisfy the same predicate the review
queue proposed from, re-checked under a row lock: a posted, unreversed,
unvoided `CASH_MOVEMENT` entry whose single attached bank line sits on
ANOTHER of this entity's bank accounts, carries the same amount in the
opposite direction within 2 days, is not pending, and whose own memo
reads as a transfer between the operator's accounts. Anything else is
422 `transfer_link_invalid`.
**Bounded and idempotent by construction.** A candidate entry must have
exactly ONE bank line attached today, so once this call succeeds the
same line cannot be linked twice and no third line can be attached to a
transfer that already has both halves.
**No GL postings occur.** One audit row
(`bank_transaction.linked_to_transfer`) and one
`bank_transaction.matched` event. Undo is the normal unmatch: the line
is restored to `unreconciled` and the journal entry is left alone.
## OpenAPI
````yaml /openapi.yaml post /accounting/bank-transactions/{id}/link-transfer
openapi: 3.1.0
info:
title: Arcus ERP Public API
version: 1.0.0
description: >
Arcus ERP public REST API. Designed for external integrations and data
migration.
**Authentication.** Bearer token (API key) via the `Authorization` header.
Format: `Authorization: Bearer ark_live_ent__` (or
`ark_test_*` for sandbox).
API keys are issued per-entity in **Settings > Developers > API Keys**.
**Entity scoping.** The entity is encoded in the API key prefix; routes are
flat
(e.g. `/v1/accounts`, `/v1/orders`, `/v1/products`). A small set of platform
endpoints
(migration, reconciliation, events, webhook endpoints, API keys) use the
`/v1/entities/{entity_id}/...` form -- those are noted in their tags.
**Key capabilities.**
- Related-resource hydration via `?expand[]=` (see `x-arcus-expand` on each resource).
- Cursor-based pagination (`starting_after` / `ending_before` / `limit`).
- Idempotency via the `Idempotency-Key` header.
- Webhook events for asynchronous notification.
- Conditional requests / ETag for cache validation.
servers:
- url: https://api.arcuserp.com/v1
description: Arcus ERP API (accepts both live `ark_live_*` and test `ark_test_*` keys)
- url: https://dev-api.arcuserp.com/v1
description: >-
Dev sandbox API (test-only data, accepts `ark_test_*` keys against dev
RDS)
security: []
paths:
/accounting/bank-transactions/{id}/link-transfer:
post:
tags:
- Accounting
summary: Link a bank line to the transfer journal entry that already booked it
description: |
Required API key scope: `accounting:write`
Links an unreconciled bank feed line to an EXISTING bank-transfer
journal entry and **posts nothing**.
**The problem it solves.** Banks post the two legs of one internal
transfer on different days. When the first leg is recorded as a transfer
and the second arrives afterwards, the second leg has no twin to be
matched against (the first is already `matched`), so the only other verb
available records a SECOND transfer entry for the same money -- one bank
GL permanently overstated, the other understated. This endpoint is the
alternative: the movement is already on the books, so the line is
attached to the entry that booked it.
**The server re-validates, and the caller cannot steer it.** The
`journal_entry_id` must still satisfy the same predicate the review
queue proposed from, re-checked under a row lock: a posted, unreversed,
unvoided `CASH_MOVEMENT` entry whose single attached bank line sits on
ANOTHER of this entity's bank accounts, carries the same amount in the
opposite direction within 2 days, is not pending, and whose own memo
reads as a transfer between the operator's accounts. Anything else is
422 `transfer_link_invalid`.
**Bounded and idempotent by construction.** A candidate entry must have
exactly ONE bank line attached today, so once this call succeeds the
same line cannot be linked twice and no third line can be attached to a
transfer that already has both halves.
**No GL postings occur.** One audit row
(`bank_transaction.linked_to_transfer`) and one
`bank_transaction.matched` event. Undo is the normal unmatch: the line
is restored to `unreconciled` and the journal entry is left alone.
operationId: linkTransferFromFeedV1
parameters:
- name: id
in: path
required: true
schema:
type: string
format: uuid
description: The bank transaction to link.
requestBody:
required: true
content:
application/json:
schema:
type: object
required:
- journal_entry_id
properties:
journal_entry_id:
type: string
format: uuid
description: >-
The already-posted transfer journal entry that booked this
movement.
responses:
'200':
description: Linked
content:
application/json:
schema:
type: object
properties:
data:
type: object
properties:
bank_transaction_id:
type: string
format: uuid
journal_entry:
type: object
properties:
id:
type: string
format: uuid
entry_number:
type: string
nullable: true
counterparty_bank_transaction_id:
type: string
format: uuid
posted_on:
type: string
format: date
nullable: true
reconciliation_status:
type: string
enum:
- matched
journal_entry_posted:
type: boolean
enum:
- false
description: 'Always false: this verb links, it never posts.'
'400':
$ref: '#/components/responses/Error'
'401':
$ref: '#/components/responses/Error'
'403':
$ref: '#/components/responses/Error'
'404':
$ref: '#/components/responses/Error'
'409':
description: >-
already_matched -- the line is already linked, or changed state
concurrently
content:
application/json:
schema:
$ref: '#/components/schemas/Error'
'422':
description: >-
transfer_link_invalid -- that entry is not the other half of this
line
content:
application/json:
schema:
$ref: '#/components/schemas/Error'
security:
- ApiKeyAuth: []
components:
responses:
Error:
description: Error response (400/401/403/404/409/422/429/500)
content:
application/json:
schema:
$ref: '#/components/schemas/ErrorEnvelope'
schemas:
Error:
description: |
Alias for ErrorEnvelope. Canonical error response shape used by all
API endpoints. Refer to ErrorEnvelope for the full field definition.
allOf:
- $ref: '#/components/schemas/ErrorEnvelope'
ErrorEnvelope:
type: object
description: |
Canonical error response envelope. All API errors use this shape.
required:
- error
- code
properties:
error:
type: string
description: Machine-readable error key
example: not_found
code:
type: string
description: Machine-readable error code (often same as error)
example: not_found
type:
type: string
enum:
- validation_error
- permission_error
- not_found
- conflict
- rate_limit
- internal
- expand_error
- not_implemented
example: not_found
hint:
type: string
description: Human-readable one-sentence explanation (English)
example: >-
The requested order does not exist or does not belong to this
entity.
param:
type: string
description: The parameter that caused the error, if applicable
example: expand[0]
required:
type: string
description: The scope required (only on insufficient_scope errors)
example: accounts:read
request_id:
type: string
description: >-
Unique request ID for support tracing (maps to CloudWatch log
stream)
example: req_abc123
securitySchemes:
ApiKeyAuth:
type: http
scheme: bearer
description: |
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.
````