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

# The reconciliation audit of one bank account, with the door for each finding

> The whole reconciliation audit of ONE bank account in one call: the answers an accountant
gives when proving a migrated or reconnected account, in the order they must be fixed.
Five answers are returned under `answers`: `feed_against_bank` (does the bank feed
reproduce the bank's own balance today and at each month end), `duplicates_and_exclusions`
(any bank event live twice; every exclusion, split into system and human, and any human
exclusion with no live twin), `books_against_bank` (the posted books against the bank at
each month end, with the unpaired bank rows and unpaired book lines listed),
`clearing_accounts` (each clearing account this bank feeds, against the money genuinely in
flight) and `error_classes` (a row matched to a reversed entry, an entry whose lines are all
one account, a payment recorded on a bank that did not pay it, a fee booked twice).

Every item in `findings` names its `class`, the audit `step` it belongs to (1 to 7),
its `severity` (`blocking` or `review`) and the `door` that fixes it (`match`, `undo`,
`move_to_this_bank_and_match`, `restore` or `review`). `next_step` is one sentence naming the
lowest-numbered blocking step, because a feed problem is fixed before the books are looked
at and the baseline is set last. Steps 4 and 7 are judgements and are marked unanswered in
`method.steps`.

A count is never a page size: every list is capped by `row_limit` and publishes its
unbounded total beside the rows it listed. A figure this audit cannot derive is `null`,
never `0`.

READ-ONLY. It writes nothing, posts nothing and calls no third party: every bank figure comes
from persisted state through the same engine as `bank-balance-as-of`, so the two cannot
disagree. It is not cheap: a migrated book of several hundred thousand entries takes seconds,
so ask for the month ends you need. The bank account must belong to the entity of the key
and be mapped to a general ledger account; otherwise the answer is 404
`bank_account_not_found`.
Requires `accounting:read` or `migration:read` scope.




## OpenAPI

````yaml /openapi.yaml get /entities/{entity_id}/reconciliation/account-audit
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.

    **Changelog.** Entries are dated and name every published contract whose
    MEANING moved, not

    only the ones whose field names changed. The narrative version of the same
    entries, written

    for integrators, is published at https://arcuserp.mintlify.app/changelog.


    **2026-09-22 (planned 2026-09-21), REORDER-BUYER-TRUTH: demand changed what
    it MEANS on three

    published contracts, with no field renamed.** An integrator that pins field
    names sees no

    breakage and different numbers, which is why this entry exists.

      - **Demand now counts build consumption.** `demand_avg_per_day` on the public product, kit
        and inventory-balance objects, and `daily_demand` / `demand_basis` / `net_suggested_qty`
        on `GET /v1/purchasing/reorder-report`, are composed from fulfilled sales lines PLUS
        posted `build_consume` inventory draws: each physical decrement of a product counts
        exactly once. The previous rule adopted an internal-consumption basis only when the sales
        blend was exactly zero, so a product both sold AND consumed into work orders planned as
        if the build draws did not exist. Products drawn into work orders move; on one
        production-shaped dataset five did, the largest from 0.05/day to 14.95/day.
      - **`demand_basis` now carries four values, not two:** `sales`, `sales_and_builds`,
        `builds` and `consumption`. A consumer with a two-branch reader (anything that is not
        `consumption` is `sales`) silently hides the two new ones.
      - **`current_demand_units` on `GET /v1/inventory/balances/:id` moved, by a second rule.**
        It counts committed-but-unshipped CUSTOMER demand, and it now counts a kit component's
        own line rather than its parent kit line, and excludes non-sales documents. On one
        production dataset 269 of 1,043 balance rows changed, 227 of them downward; the largest
        single move was 1,941 to 25, on a product whose open PURCHASE order line had been
        reported as customer demand. Re-baseline anything that alerts or reorders off this field.
      - `run_rate_30/90/180/365` and `blended_daily` on the same balance object move for the
        first reason above.
      - **Added, not changed:** `GET /v1/purchasing/reorder-report` accepts `demand_window` and
        returns the unit, cover-through and reorder-point-provenance fields documented on that
        operation; `order_multiple` is accepted and returned on the product-vendor doors.
      - **Volume note.** The `inventory.low_stock`, `inventory.out_of_stock` and
        `inventory.back_in_stock` webhook events are population-gated on
        `on_hand <= reorder_point`, and reorder points move with the demand above, so
        subscribers should expect a one-time step change in event volume around the release.
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:
  /entities/{entity_id}/reconciliation/account-audit:
    get:
      tags:
        - Reconciliation
      summary: >-
        The reconciliation audit of one bank account, with the door for each
        finding
      description: >
        The whole reconciliation audit of ONE bank account in one call: the
        answers an accountant

        gives when proving a migrated or reconnected account, in the order they
        must be fixed.

        Five answers are returned under `answers`: `feed_against_bank` (does the
        bank feed

        reproduce the bank's own balance today and at each month end),
        `duplicates_and_exclusions`

        (any bank event live twice; every exclusion, split into system and
        human, and any human

        exclusion with no live twin), `books_against_bank` (the posted books
        against the bank at

        each month end, with the unpaired bank rows and unpaired book lines
        listed),

        `clearing_accounts` (each clearing account this bank feeds, against the
        money genuinely in

        flight) and `error_classes` (a row matched to a reversed entry, an entry
        whose lines are all

        one account, a payment recorded on a bank that did not pay it, a fee
        booked twice).


        Every item in `findings` names its `class`, the audit `step` it belongs
        to (1 to 7),

        its `severity` (`blocking` or `review`) and the `door` that fixes it
        (`match`, `undo`,

        `move_to_this_bank_and_match`, `restore` or `review`). `next_step` is
        one sentence naming the

        lowest-numbered blocking step, because a feed problem is fixed before
        the books are looked

        at and the baseline is set last. Steps 4 and 7 are judgements and are
        marked unanswered in

        `method.steps`.


        A count is never a page size: every list is capped by `row_limit` and
        publishes its

        unbounded total beside the rows it listed. A figure this audit cannot
        derive is `null`,

        never `0`.


        READ-ONLY. It writes nothing, posts nothing and calls no third party:
        every bank figure comes

        from persisted state through the same engine as `bank-balance-as-of`, so
        the two cannot

        disagree. It is not cheap: a migrated book of several hundred thousand
        entries takes seconds,

        so ask for the month ends you need. The bank account must belong to the
        entity of the key

        and be mapped to a general ledger account; otherwise the answer is 404

        `bank_account_not_found`.

        Requires `accounting:read` or `migration:read` scope.
      operationId: getReconciliationAccountAudit
      parameters:
        - name: entity_id
          in: path
          required: true
          schema:
            type: string
            format: uuid
        - name: bank_account_id
          in: query
          required: true
          schema:
            type: string
            format: uuid
        - name: as_of
          in: query
          description: YYYY-MM-DD. Defaults to today.
          schema:
            type: string
            format: date
        - name: month_ends
          in: query
          description: How many month ends before `as_of` to test, 1 to 36.
          schema:
            type: integer
            minimum: 1
            maximum: 36
        - name: since
          in: query
          description: >-
            YYYY-MM-DD. Limits the clearing and error-class answers to activity
            on or after this day.
          schema:
            type: string
            format: date
        - name: pairing_window_days
          in: query
          description: >-
            How many days apart an unpaired bank row and an unpaired book line
            of the same amount may be and still be offered as a pair.
          schema:
            type: integer
        - name: error_window_days
          in: query
          description: >-
            How many days apart two same-amount vendor payments may be and still
            be reported as a possible double payment.
          schema:
            type: integer
        - name: row_limit
          in: query
          description: >-
            The most rows any one list returns. Each list still publishes its
            unbounded total.
          schema:
            type: integer
      responses:
        '200':
          description: The audit of that bank account
          content:
            application/json:
              schema:
                type: object
                properties:
                  object:
                    type: string
                    enum:
                      - reconciliation_account_audit
                  entity_id:
                    type: string
                    format: uuid
                  bank_account:
                    type: object
                    description: >-
                      The account audited, its mapped general ledger account and
                      the bank's last persisted balance.
                    properties:
                      id:
                        type: string
                        format: uuid
                      name:
                        type: string
                      last4:
                        type: string
                        nullable: true
                      gl_account_id:
                        type: string
                        format: uuid
                      gl_account_number:
                        type: string
                      gl_account_name:
                        type: string
                      normal_balance:
                        type: string
                      plaid_connected:
                        type: boolean
                      bank_stated_balance:
                        type: number
                        format: double
                        nullable: true
                      bank_stated_as_of:
                        type: string
                        format: date-time
                        nullable: true
                      baseline_date:
                        type: string
                        format: date
                        nullable: true
                      baseline_balance:
                        type: number
                        format: double
                        nullable: true
                  as_of:
                    type: string
                    format: date
                  month_ends:
                    type: array
                    items:
                      type: string
                      format: date
                  since:
                    type: string
                    format: date
                    nullable: true
                  method:
                    type: object
                    description: >-
                      The audit method's steps, and which of them this read
                      answers.
                    properties:
                      document:
                        type: string
                      steps:
                        type: array
                        items:
                          type: object
                          properties:
                            key:
                              type: string
                            step:
                              type: integer
                            answered:
                              type: boolean
                            title:
                              type: string
                  answers:
                    type: object
                    description: >-
                      The five answers, each with its own figures, rows and
                      findings.
                    properties:
                      feed_against_bank:
                        type: object
                      duplicates_and_exclusions:
                        type: object
                      books_against_bank:
                        type: object
                      clearing_accounts:
                        type: object
                      error_classes:
                        type: object
                  findings:
                    type: array
                    items:
                      type: object
                      properties:
                        class:
                          type: string
                        step:
                          type: integer
                        door:
                          type: string
                          enum:
                            - match
                            - undo
                            - move_to_this_bank_and_match
                            - restore
                            - review
                        severity:
                          type: string
                          enum:
                            - blocking
                            - review
                        headline:
                          type: string
                        detail:
                          type: string
                        amount:
                          type: number
                          format: double
                          nullable: true
                        count:
                          type: integer
                          nullable: true
                  finding_count:
                    type: integer
                  blocking_count:
                    type: integer
                  next_step:
                    type: string
                  writes_nothing:
                    type: boolean
        '400':
          $ref: '#/components/responses/Error'
        '401':
          $ref: '#/components/responses/Error'
        '403':
          $ref: '#/components/responses/Error'
        '404':
          $ref: '#/components/responses/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:
    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.

````