Pre-settlements

A pre-settlement (relación de envío in Colombia) is the bundle of invoices your billing system hands over to a payer in one delivery. Where a charge is one line and an invoice groups charges, a pre-settlement groups invoices — it is the last step of the cycle, after invoicing and before the payer takes over.

The bundle is identified by an origin_invoice_group_id that you choose, the same way origin_event_id identifies an event. RCM never invents it.

Where it sits in the flow

Validate before you generate

Not every invoice is eligible to be bundled, and an invoice may already belong to a group. Check first:

• GET /v1/pre-settlements/validate-invoice — one invoice by invoice_number. Returns its internal id, the origin_invoice_group_id it belongs to (empty when it is not grouped yet) and its status.
• POST /v1/pre-settlements/validate-invoices-bulk — up to 1000 invoice numbers per call, returned already grouped by origin_invoice_group_id, each group with its own group_status.

The bulk variant is the practical one when closing a cycle: you hand over everything you intend to dispatch and the response tells you how it will be grouped and what is not eligible, in one round trip.

Generating the bundle

POST /v1/pre-settlements/generate is multipart/form-data, the same two-part shape as the support-file uploads:

Part	Content-Type	What
file	binary	Optional cover document for the bundle.
request_data	application/json	The pre-settlement itself.

Inside request_data:

Field	Required	Description
origin_invoice_group_id	yes	Your identifier for the group.
invoices	yes	Invoice numbers the bundle contains. At least one.
settlement_number	no	The payer's settlement number, when you already have it.
resolution_type	no	Colombia only: RESOLUTION_3374 or RESOLUTION_2275.

The response is 204 with no body — so read the result back with GET /v1/pre-settlements/{originInvoiceGroupId}, which returns the status, the delivery_responsible, every invoice with its package_status, and the files attached to the bundle.

Voiding, and removing single invoices

DELETE /v1/pre-settlements/{originInvoiceGroupId}/void does two different things depending on whether you send a body:

• No body → the whole group is voided.
• invoice_numbers in the body → only those invoices are detached, and the rest of the group stands.

That distinction is easy to miss, and the two outcomes are not equally recoverable — neither is reversible through the API.

Voiding a group does not void the invoices inside it. To void an invoice itself (moving its account to VOIDED and disabling its charges) use PUT /v1/invoices/{invoiceNumber}/void.

Endpoints

Operation	Endpoint
Validate one invoice	GET /v1/pre-settlements/validate-invoice
Validate a batch	POST /v1/pre-settlements/validate-invoices-bulk
Generate the bundle	POST /v1/pre-settlements/generate
Read the bundle	GET /v1/pre-settlements/{originInvoiceGroupId}
Void / detach invoices	DELETE /v1/pre-settlements/{originInvoiceGroupId}/void

Common pitfalls

• Generating without validating first. An invoice that already belongs to another group, or that is not eligible, will not silently move — validate first and correct the list.
• Expecting a body from generate. It returns 204. Everything you need afterwards comes from the detail endpoint.
• Sending an empty body to void when you meant to detach one invoice. No body voids the entire group.
• Exceeding 1000 invoice numbers in validate-invoices-bulk → 422. Split the batch.
• Assuming voiding the group voids the invoices. It does not; they go back to being ungrouped.

Related concepts

• Charges — the billable lines that end up inside the invoices.
• Support files — the documents each charge needs before it can be invoiced.
• Accounts — the billing wrapper the invoices resolve against.