> ## 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. # Change which invoices a posted customer receipt pays > Re-attributes a POSTED customer receipt across a different set of the same customer's invoices. Use it when cash was recorded correctly but applied to the wrong invoices, which is what happens whenever a receipt is booked without an applications[] payload and the server auto-applies it oldest-first while the customer's remittance advice names a different set. THIS MOVES NO CASH AND POSTS NO JOURNAL ENTRY. The receipt's amount, its date, its bank-transaction link and its journal entry are all untouched: the entry that recorded the cash (DR bank / CR Accounts Receivable) was already correct, and only the SUBLEDGER attribution was wrong. The handler fingerprints that entry, header and every line, before and after the rewrite and refuses to commit if a single byte moved. WHAT MUST HOLD, each refused with its own 422 code: * applications_sum_mismatch - the new set must total exactly what the receipt currently has applied (for a fully applied receipt that is its face amount). The receipt's entry credits Accounts Receivable by that figure, so changing the total here would break the AR-to-GL tie. * invoice_on_another_account - every invoice must belong to the customer who sent the cash. * application_exceeds_balance - an invoice may receive at most what it is open for once THIS receipt's existing contribution to it is taken back off. The response carries `room`, so a caller can retry without guessing. * application_target_not_receivable / order_not_payable - the canonical target rules the Receive Payment door enforces, so this door can never accept a document that one would refuse. * period_closed - the receipt's own accounting period is closed. The response names the period and the next open one. The correction is NOT silently rolled forward: a re-application is dated by the receipt it corrects. * receipt_not_posted / receipt_not_reappliable_tender - voided, refunded, returned and pending receipts, and the non-cash 'terms' and 'discount' rows, are refused. * receipt_gl_subledger_mismatch - the receipt is already out of tie with its own entry, so its applications are not moved from here. SIDE EFFECTS. Every invoice on either side of the change is recomputed through the canonical AR writer. Credit-terms placeholders follow: a placeholder this receipt had retired is reopened when the receipt stops settling its invoice, and one is retired when an invoice now reaches zero. Two audit records are written, one on the receipt carrying the whole before and after set and one on each invoice whose share moved. Broadcasts payment.applications_changed plus per-invoice order.payment_status_changed. UNDO. The response carries an `undo` object holding the PRIOR set in the exact shape this endpoint accepts, so reverting is one more call with that body. NOT the same verb as POST /v1/payments/{id}/apply, which applies an UNALLOCATED receipt and refuses an already-applied one (payment_already_applied). This one is the correction of an allocation that already exists. Idempotent via the Idempotency-Key header. ## OpenAPI ````yaml /openapi.yaml patch /customer-payments/{id}/applications 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. **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: /customer-payments/{id}/applications: patch: tags: - Payments summary: Change which invoices a posted customer receipt pays description: > Re-attributes a POSTED customer receipt across a different set of the same customer's invoices. Use it when cash was recorded correctly but applied to the wrong invoices, which is what happens whenever a receipt is booked without an applications[] payload and the server auto-applies it oldest-first while the customer's remittance advice names a different set. THIS MOVES NO CASH AND POSTS NO JOURNAL ENTRY. The receipt's amount, its date, its bank-transaction link and its journal entry are all untouched: the entry that recorded the cash (DR bank / CR Accounts Receivable) was already correct, and only the SUBLEDGER attribution was wrong. The handler fingerprints that entry, header and every line, before and after the rewrite and refuses to commit if a single byte moved. WHAT MUST HOLD, each refused with its own 422 code: * applications_sum_mismatch - the new set must total exactly what the receipt currently has applied (for a fully applied receipt that is its face amount). The receipt's entry credits Accounts Receivable by that figure, so changing the total here would break the AR-to-GL tie. * invoice_on_another_account - every invoice must belong to the customer who sent the cash. * application_exceeds_balance - an invoice may receive at most what it is open for once THIS receipt's existing contribution to it is taken back off. The response carries `room`, so a caller can retry without guessing. * application_target_not_receivable / order_not_payable - the canonical target rules the Receive Payment door enforces, so this door can never accept a document that one would refuse. * period_closed - the receipt's own accounting period is closed. The response names the period and the next open one. The correction is NOT silently rolled forward: a re-application is dated by the receipt it corrects. * receipt_not_posted / receipt_not_reappliable_tender - voided, refunded, returned and pending receipts, and the non-cash 'terms' and 'discount' rows, are refused. * receipt_gl_subledger_mismatch - the receipt is already out of tie with its own entry, so its applications are not moved from here. SIDE EFFECTS. Every invoice on either side of the change is recomputed through the canonical AR writer. Credit-terms placeholders follow: a placeholder this receipt had retired is reopened when the receipt stops settling its invoice, and one is retired when an invoice now reaches zero. Two audit records are written, one on the receipt carrying the whole before and after set and one on each invoice whose share moved. Broadcasts payment.applications_changed plus per-invoice order.payment_status_changed. UNDO. The response carries an `undo` object holding the PRIOR set in the exact shape this endpoint accepts, so reverting is one more call with that body. NOT the same verb as POST /v1/payments/{id}/apply, which applies an UNALLOCATED receipt and refuses an already-applied one (payment_already_applied). This one is the correction of an allocation that already exists. Idempotent via the Idempotency-Key header. operationId: reapplyCustomerPaymentApplications parameters: - name: id in: path required: true schema: type: string format: uuid description: The order_payments id of the posted receipt to re-apply. - $ref: '#/components/parameters/IdempotencyKey' requestBody: required: true content: application/json: schema: type: object required: - applications properties: applications: type: array minItems: 1 maxItems: 50 description: > The NEW set, complete. Every invoice this receipt should pay must appear, with the whole amount it receives; an invoice left out stops being paid by this receipt and its balance returns. Each invoice may appear once. items: type: object required: - order_id - amount properties: order_id: type: string format: uuid description: The invoice (orders.id) receiving the money. amount: type: number description: >- Dollars applied to this invoice. Must be greater than zero. reason: type: string description: > Why the attribution changed, for example "Customer remittance advice". Recorded on every audit record this call writes. responses: '200': description: The receipt was re-applied content: application/json: schema: type: object properties: data: type: object properties: payment_id: type: string format: uuid account_id: type: string format: uuid receipt_amount: type: number applications_total: type: number journal_entry_id: type: string format: uuid nullable: true journal_entry_unchanged: type: boolean description: >- Always true on success; the call refuses to commit otherwise. applications_before: type: array description: The set as it stood before this call. items: type: object applications: type: array description: The set as it stands now. items: type: object terms_placements_reopened: type: array description: >- Credit-terms placeholders put back on terms because this receipt stopped settling their invoice. items: type: object properties: order_id: type: string format: uuid placement_ids: type: array items: type: string format: uuid terms_placements_settled: type: array description: >- Credit-terms placeholders retired because their invoice now reaches zero. items: type: object properties: order_id: type: string format: uuid placement_ids: type: array items: type: string format: uuid undo: type: object description: The prior set, in the shape this endpoint accepts. properties: payment_id: type: string format: uuid applications: type: array items: type: object properties: order_id: type: string format: uuid amount: type: number '400': $ref: '#/components/responses/Error' '401': $ref: '#/components/responses/Error' '403': $ref: '#/components/responses/Error' '404': $ref: '#/components/responses/Error' '422': $ref: '#/components/responses/Error' security: - ApiKeyAuth: [] 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__ Test keys use ark_test_ent__. Both are issued per entity via Settings > Developers > API Keys. ````