RipsCloud supports health invoices when the RIPS process needs a companion document. It uses **PahFacturar** for document emission. Your integration calls RipsCloud; it does not need a SISPRO token or a PahFacturar credential.

:::caution[Separate acceptances]
DIAN acceptance of an invoice or note does not mean FEV RIPS accepted its RIPS. Prepare, validate, and dispatch the companion package separately.
:::

## Health invoice

1. Read [health invoice context](/reference/operations/health-invoices-get-context/) for the configured company and available setup.
2. Map authorized patients, services, payer, resolution, amounts, and payment terms into [Emit a health document](/reference/operations/health-invoices-emit/).
3. Send one `Idempotency-Key` for that emission intent.
4. Read the document state. Resolve an uncertain provider result before retrying.
5. After acceptance, call [Prepare the companion RIPS](/reference/operations/health-invoices-prepare-rips-package/).
6. Follow the [RIPS lifecycle](/guides/rips-lifecycle/) for the returned package.

This is a health-document flow. Do not use it for commercial invoices or general accounting.

## Credit notes

Read the source invoice's [credit-note context](/reference/operations/credit-notes-get-context/) before selecting items and amounts. The server checks the accepted source and relevant balance constraints. Emit the credit note with an idempotency key. After acceptance, prepare its companion RIPS using the credit-note package operation.

Use the credit-note kind that matches the actual process. Partial and total notes have different RIPS requirements. Read the [package type table](/guides/rips-lifecycle/#choose-a-package-type).

## Debit notes

Read [debit-note context](/reference/operations/debit-notes-get-context/) for the accepted source invoice. A debit note needs **additional service RIPS**. Supply the supplemental services with the debit-note payload; do not reuse old services as additional charges.

The server checks positive amounts, patient identity, source evidence, and consistency between the note lines and the supplemental RIPS. The DIAN debit reasons are `1` Interest, `2` Expenses receivable, `3` Change in value, and `4` Other.

1. Call [Emit a debit note](/reference/operations/debit-notes-emit/) with the source invoice, note payload, supplemental RIPS, and a unique idempotency key.
2. Read the note until its provider outcome is known.
3. After DIAN acceptance, [prepare the RIPS package](/reference/operations/debit-notes-prepare-rips-package/).
4. Validate and dispatch that `nd` package separately.

## RIPS adjustment notes

An adjustment note is a RIPS package with `kind: "nota_ajuste"`. Reference an accepted source package and supply the corrected RIPS. This kind does not attach a new invoice XML. It is different from a credit note or debit note.

Use [Create RIPS packages](/reference/operations/rips-packages-create/) to prepare the draft. Creating it does not send it.

## Artifacts and delivery

Artifact endpoints return binary responses with the content type specified in the contract. Handle them as files, not JSON. Check the endpoint's allowed artifact values; debit notes offer signed XML and AttachedDocument, not a promised PDF.

Email is another external action with its own idempotency key and configuration requirements. If the result is `email_outcome_unknown`, do not resend automatically or change the key to bypass the state. Confirm delivery before another intent.