Factuarea APIDevelopers

Revert an invoice payment

Void a payment recorded against an invoice, stating why.

  • The payment keeps its amount, date, method and reference and is flagged as reverted (is_reversed: true) together with the reason, the instant and the author — it is never deleted, because a payment that existed and stopped having effect is accounting information.

  • reason is required and belongs to a closed catalog: direct_debit_return (returned SEPA direct debit), card_dispute (card chargeback or reversal), misapplied_payment (booked against the wrong invoice), bounced_effect (dishonoured bill) and recording_error.

  • A value outside the catalog returns 422 payment_reversal_reason_invalid.

  • note is an optional free-text remark of up to 500 characters; going over returns 422 payment_reversal_invalid.

  • Reverting a payment that is already reverted returns 422 payment_already_reversed.

  • A reverted payment stops counting towards paid_amount, pending_amount and every treasury aggregate, so the invoice goes back into the collection circuit: overdue if its due date has passed, sent otherwise, and it accepts a new payment again.

  • That transition is derived from the ledger and can only originate here — the generic status-change endpoint cannot move an invoice out of paid.

  • Refund or reversal? Revert when the customer got their money back without the operation being reduced (returned direct debit, chargeback, booking mistake): the debt survives and you want to collect it.

  • Issue a corrective invoice (POST /v1/invoices/{id}/corrective) when the operation itself is reduced — that is where revenue actually decreases.

  • Reverting never issues a corrective, and a returned receipt is not a bad-debt claim (art. 80.Cuatro LIVA has its own formal requirements).

  • Irreversible: there is no un-revert.

  • To restate the collection, register a new payment.

POST
/invoices/{invoice}/payments/{payment}/reversal
AuthorizationBearer <token>

In: header

Path Parameters

invoice*string
payment*string

Headers

Idempotency-Key*string

Client-generated opaque key (up to 255 characters; UUID v7 recommended) that makes retries safe: the first response is cached and replayed for repeats without re-executing the mutation. Reusing a key with a different body returns 409 idempotency_key_reused. See the Idempotency guide. Required on this operation: repeating it delivers an effect that cannot be taken back (an email sent, a file generated, a third-party call, a charge), so a request without this header is rejected with 422 idempotency_key_required before any business logic runs.

Length1 <= length <= 255
Factuarea-Version?string

Pin the API version (YYYY-MM-DD, Stripe-style date versioning) for this request; omit to use the key's pinned version, or the latest if none. Unsupported version → 400 unsupported_api_version; malformed → 400 parameter_invalid_format. The effective version is echoed in the Factuarea-Version response header. See the Versioning guide.

Formatdate
X-Active-Profile?string

Operate on behalf of a child company (gestoría master key): pass its public id (UUID v7) and the request runs against that child's data without changing the key's scope, tier or environment (omit to use the key's own company). Invalid UUID → 400 parameter_invalid_uuid; unknown or non-owned id → 404 profile_not_found. See the Acting on behalf guide.

Formatuuid

Request Body

application/json

TypeScript Definitions

Use the request body type in TypeScript.

Response Body

application/json

application/json

application/json

application/json

application/json

application/json

application/json

application/json