# Why SHA gets one claim

  A provider may hold several invoices for one visit. SHA is only ever sent one claim for it.

## What differs between payers

Payers do not pay for the same thing.

| | SHA | Slade EDI payers |
| --- | --- | --- |
| What the payer pays against | An **intervention**, one amount per service line | An **invoice** |
| How many claims a visit sends | One comprehensive claim | One per invoice number |
| What the provider states | How much is charged for each service line | The invoice and what is on it |

SHA has always worked from the service line. At the SHA billing portal a provider signs in and states
how much they are charging for each service line of the visit. The invoice number on that claim is
generated for them, though they can key one in by hand. How many invoices the provider holds for the
visit on their own side never reaches SHA.

## What the rail does about it

The rail already prices what SHA pays against, because every bill line names the service line it
draws on. The claim is therefore built from the lines, per intervention, and nobody has to total an
invoice and send it across.

An invoice number is the one thing the two kinds of payer need from you differently.

<Wire
  rows={[
    { call: "When the visit opens", does: "Send `visit_number` and `invoice_number`. On SHA this is the invoice number the one claim is submitted under.", keep: "—" },
    { call: "On each bill item", does: "Name the `invoice_number` the charge belongs to. On a Slade cover it picks the claim, and a new number opens one. On SHA it is accepted and the charge still joins the one claim.", keep: "claim_ref" },
    { call: "At close", does: "Every claim on the visit is sent. SHA receives one comprehensive claim; a Slade payer receives one per invoice.", keep: "claims[].claim_ref" },
  ]}
/>

## Why one claim, and why that invoice number

**One claim, because SHA pays per intervention.** The amount SHA pays against is stated for each
service line, so the invoices a provider holds for the visit are not what it works from. The provider
keeps as many invoices as they need; SHA is sent one claim carrying the service lines.

**That invoice number, because it is the one the provider gave.** The invoice number is the
provider's own, given rather than minted, so SHA's record can be reconciled against the provider's.
At the SHA portal the number is generated for the provider unless they key one in. Here you send it
when the visit opens, and it is the number the one claim is submitted under.

## What this means for your integration

- Send `invoice_number` on every open, SHA or not.
- Name an invoice on each bill item as you bill. You do not have to line your invoices up with SHA's
  single claim: on a SHA cover the number on a bill item is yours, and it does not change what is sent.
- Do not try to split a SHA visit into several claims. Split only where the payer pays per invoice.
- A visit with a SHA cover and a Slade cover sends both: one comprehensive claim to SHA, and one
  claim per invoice to the Slade payer.

See [04 · Visit](/rail/stops/Visit#the-visit-and-invoice-numbers) for the numbers at open,
[07 · Bill](/rail/stops/Bill#which-invoice-a-charge-belongs-to) for naming an invoice on a charge, and
[08 · Submit](/rail/stops/Submit#pre-flight-what-is-checked) for the check that runs before close.