> ## 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. # Void a payment batch > **Authorization:** requires `purchasing:write` API-key scope AND the per-user `payments.refund_void` permission (SoD parity sweep 2026-05-16). Voiding a NACHA payment batch cascade-deletes the underlying `ap_payments` rows + `ap_payment_applications` rows for the batch: effectively a bulk void of every payment in the batch. Industry pattern treats bank-batch reversal as the most-trusted AP action, hence the elevated per-user gate. System-actor calls without an identifiable principal are denied per AICPA SoC2 CC6.1. State transitions enforced by the canonical `voidPaymentBatch` handler: - If batch `status = 'confirmed_sent'`: HTTP 409 `cannot_void_confirmed_batch`. Confirmed-sent batches have posted GL (DR Accounts Payable / CR Bank) and are bank-transmitted. To reverse, void each individual `ap_payment` via `DELETE /v1/ap-payments/{id}` (each payment void reverses its own GL journal entry). - If batch `status = 'voided'`: HTTP 200 no-op (idempotent). - Otherwise (draft / nacha_generated): the cascade runs atomically inside one transaction. No GL reversal needed because Track I defers GL posting to confirm-sent; draft/generated batches have not posted. The voided batch row is retained (status -> voided, total_cents -> 0) for audit trail. Body fields are optional; `reason` is logged to the activity feed and broadcast on the `payment_batch.voided` event. ## OpenAPI ````yaml /openapi.yaml delete /ap-payments/batches/{batchId} 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: /ap-payments/batches/{batchId}: parameters: - name: batchId in: path required: true schema: type: string format: uuid delete: tags: - Purchasing summary: Void a payment batch description: > **Authorization:** requires `purchasing:write` API-key scope AND the per-user `payments.refund_void` permission (SoD parity sweep 2026-05-16). Voiding a NACHA payment batch cascade-deletes the underlying `ap_payments` rows + `ap_payment_applications` rows for the batch: effectively a bulk void of every payment in the batch. Industry pattern treats bank-batch reversal as the most-trusted AP action, hence the elevated per-user gate. System-actor calls without an identifiable principal are denied per AICPA SoC2 CC6.1. State transitions enforced by the canonical `voidPaymentBatch` handler: - If batch `status = 'confirmed_sent'`: HTTP 409 `cannot_void_confirmed_batch`. Confirmed-sent batches have posted GL (DR Accounts Payable / CR Bank) and are bank-transmitted. To reverse, void each individual `ap_payment` via `DELETE /v1/ap-payments/{id}` (each payment void reverses its own GL journal entry). - If batch `status = 'voided'`: HTTP 200 no-op (idempotent). - Otherwise (draft / nacha_generated): the cascade runs atomically inside one transaction. No GL reversal needed because Track I defers GL posting to confirm-sent; draft/generated batches have not posted. The voided batch row is retained (status -> voided, total_cents -> 0) for audit trail. Body fields are optional; `reason` is logged to the activity feed and broadcast on the `payment_batch.voided` event. operationId: voidPaymentBatchV1 requestBody: required: false content: application/json: schema: type: object properties: reason: type: string description: Operator-supplied void reason (audit-logged). responses: '200': description: | Batch voided (or already voided no-op). Response body: `{ data: { id, status: 'voided', removed_payments: } }`. content: application/json: schema: type: object properties: data: type: object properties: id: type: string format: uuid status: type: string enum: - voided removed_payments: type: integer minimum: 0 message: type: string '400': description: | Pre-flight gate blocked the void. Possible `code` values: `entity_id required` (caller scope missing entity context). content: application/json: schema: $ref: '#/components/schemas/Error' '401': $ref: '#/components/responses/Error' '403': description: | Permission denied. Possible `code` values: missing per-user `payments.refund_void` permission, or scope-only API-key call without an identifiable principal (SoC2 CC6.1). content: application/json: schema: $ref: '#/components/schemas/Error' '404': description: | Batch not found in the caller's entity. `code: batch_not_found`. content: application/json: schema: $ref: '#/components/schemas/Error' '409': description: | Conflict: batch state blocks the void. Possible `code` values: `cannot_void_confirmed_batch` (confirmed-sent batch; void each payment individually instead). content: application/json: schema: $ref: '#/components/schemas/Error' security: - ApiKeyAuth: [] components: 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 responses: Error: description: Error response (400/401/403/404/409/422/429/500) content: application/json: schema: $ref: '#/components/schemas/ErrorEnvelope' 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. ````