> ## 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.

# Stamp the bank account a printed check was drawn on

> Records which bank account a printed check was drawn on, so the
clearing relief can be posted against the right account.

`POST /printed-checks/{id}/clear` refuses with `422
check_clear_drawee_unknown` when neither the bill payment that
issued the check nor the check itself records a drawee bank. It
does not fall back to a default operating bank, because a default
is a guess and a guess moves money out of the wrong account. This
endpoint is how that refusal is resolved.

In one transaction it writes `printed_checks.bank_account_id`
always, and `ap_payments.bank_account_id` only when that payment
is currently unstamped. A payment that already names a bank is
left alone: re-pointing a posted payment's bank is a reclass with
GL consequences, not a data-entry fix.

Only a check in `printed` status can be stamped. A cleared check
has already posted its relief against the bank it named at the
time, so changing the drawee afterwards is a reversal and a
re-post rather than an edit. The bank account must belong to the
calling entity and its GL must be a postable, non-header account
with a bank record, which is exactly what the clear verb will
demand of it later.

The canonical handler enforces handler-top SoD via the api-key's
`created_by_user_id` and requires the `accounting.post`
permission in addition to the `purchasing:write` scope.
Idempotent via Idempotency-Key.




## OpenAPI

````yaml /openapi.yaml patch /printed-checks/{id}/bank
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_<code>_<random>` (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:
  /printed-checks/{id}/bank:
    parameters:
      - name: id
        in: path
        required: true
        schema:
          type: string
          format: uuid
    patch:
      tags:
        - Purchasing
      summary: Stamp the bank account a printed check was drawn on
      description: |
        Records which bank account a printed check was drawn on, so the
        clearing relief can be posted against the right account.

        `POST /printed-checks/{id}/clear` refuses with `422
        check_clear_drawee_unknown` when neither the bill payment that
        issued the check nor the check itself records a drawee bank. It
        does not fall back to a default operating bank, because a default
        is a guess and a guess moves money out of the wrong account. This
        endpoint is how that refusal is resolved.

        In one transaction it writes `printed_checks.bank_account_id`
        always, and `ap_payments.bank_account_id` only when that payment
        is currently unstamped. A payment that already names a bank is
        left alone: re-pointing a posted payment's bank is a reclass with
        GL consequences, not a data-entry fix.

        Only a check in `printed` status can be stamped. A cleared check
        has already posted its relief against the bank it named at the
        time, so changing the drawee afterwards is a reversal and a
        re-post rather than an edit. The bank account must belong to the
        calling entity and its GL must be a postable, non-header account
        with a bank record, which is exactly what the clear verb will
        demand of it later.

        The canonical handler enforces handler-top SoD via the api-key's
        `created_by_user_id` and requires the `accounting.post`
        permission in addition to the `purchasing:write` scope.
        Idempotent via Idempotency-Key.
      operationId: updateCheckBankV1
      parameters:
        - $ref: '#/components/parameters/IdempotencyKey'
      requestBody:
        required: true
        content:
          application/json:
            schema:
              type: object
              required:
                - bank_account_id
              properties:
                bank_account_id:
                  type: string
                  format: uuid
                  description: The bank account this check was drawn on.
      responses:
        '200':
          description: Drawee bank stamped on the check
          content:
            application/json:
              schema:
                type: object
        '400':
          $ref: '#/components/responses/Error'
        '404':
          $ref: '#/components/responses/Error'
        '422':
          $ref: '#/components/responses/Error'
      security:
        - ApiKeyAuth:
            - purchasing:write
components:
  parameters:
    IdempotencyKey:
      name: Idempotency-Key
      in: header
      required: false
      description: |
        Client-generated unique key for idempotent POST/PATCH/DELETE operations.
        Alias for the Idempotency parameter. Max 255 chars. On retry with the
        same key, the original response is returned without re-executing the
        operation. Keys expire after 24 hours.
      schema:
        type: string
        maxLength: 255
  responses:
    Error:
      description: Error response (400/401/403/404/409/422/429/500)
      content:
        application/json:
          schema:
            $ref: '#/components/schemas/ErrorEnvelope'
  schemas:
    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_<code>_<random>
        Test keys use ark_test_ent_<code>_<random>. Both are issued per entity
        via Settings > Developers > API Keys.

````