Update a bank allocation
PATCH/api/v1/bank_allocations/:id
Changes the drafted amount, or withdraws the allocation by setting status: "rejected". Both fields are optional but at least one is required; the fields you send are applied and the rest keep their stored values.
rejected is the only status this endpoint writes. A confirmation is POST /api/v1/bank_operations/{id}/reconciliation, and an allocation that has already been decided can never return to proposed. A CONFIRMED allocation cannot be rejected here either: the money has to come back first, through DELETE /api/v1/bank_operations/{id}/reconciliation.
Idempotency-Key is accepted and optional.
Request
Responses
- 200
- 401
- 403
- 404
- 422
The updated allocation.
The request carries no bearer token, or one that is invalid or expired.
The token does not hold the write scope, or the bank_reconciliation feature is off for the allocation's workspace.
No allocation with this id is reachable by the token's grants.
The body was refused. details names the field. Causes: no writable field at all; a negative or unparseable allocated_amount; a status other than rejected; an amount that would make the operation's active allocations exceed the movement (allocation_exceeds_operation); an allocation whose current state cannot be rejected - confirmed and the terminal rejected.
allocated_amount can only be changed while the allocation is still a draft - proposed or unconfirmed. On a confirmed one it is refused, because the amount is not the only record of what was settled: an Invoice::Payment and a counterparty line on the accounting entry say the same thing, and editing the column alone would leave the three disagreeing. Resize a settled allocation by sending the complete intended set to POST /api/v1/bank_operations/{id}/reconciliation, which withdraws and re-confirms in one transaction and checks the export lock. On a rejected allocation it is refused too: a refusal is terminal and its record is not rewritten.