---
id: KB-CD-019
url: https://app.codecontract.io/help/credits-and-billing/if-something-fails-was-it-still-charged
idioma: en
categoria: creditos
audiencia: usuario
nivel: basico
actualizado: 2026-08-13
tambienEn: [es]
relacionados: [KB-CD-009, KB-CD-016]
citadoPor: [KB-CD-003]
---

# If something fails, was it still charged?

_The question that follows the first bounced message, and the rule that answers it for every case._

**Responde a:** the email bounced and I was charged · are credits used if a send fails · does retrying consume again · charged even if they never got it

You send a request, the address was wrong and the message bounces. The question asks itself: if it never arrived, why does the usage show? The answer is consistent, even if it does not look that way the first time.

## The rule, and how it applies

| What happened | Was the action performed | How it ends up |
| --- | --- | --- |
| The message went out and bounced | Yes: it was prepared and sent | Recorded as done, and the detail shows it |
| The recipient never opened it | Yes | Same: what was done was sending it |
| You cancelled before sending | No | There was no action |
| Retrying after fixing the address | Yes, it is another action | It counts as the send it is |
| Viewing or downloading what already exists | Not an action of this kind | It does not add up |

> [!IMPORTANT]
> The logic behind all this is not the outcome, it is the work done: **what is recorded is what the platform does for you towards the outside, not what the recipient decides to do**. Whether they open it, reply or bin it is not in your hands or anyone's here. If usage depended on the other side answering, half of what you do could not be measured — and the practical consequence is the opposite of what it seems: **fixing before sending is worth more than retrying afterwards**.

## How repeat spend is avoided

1. **Check the address before the first send** — Especially for new contacts or ones imported from another system.
2. **On a large batch, test with two first** — If the template has an error, it shows there and not four hundred times.
3. **And fix the contact card, not just the send** — Otherwise the next person to write hits the same thing.

> [!WARNING]
> A detail worth knowing before retrying in the heat of the moment: **what has gone out is not undone by repeating it**. A sent message is sent, and resending does not replace it: there are two, and the recipient sees both. If the aim was to correct something, cancel the earlier one where possible and explain it in the new one, rather than resending three times hoping the good one sticks.

## Where it is actually checked

**En corto**

- Your account detail shows each action with its date and what it relates to.
- Each organisation can have its own policy, so that detail overrides any general list.
- And if something does not add up, that is exactly what support needs: the specific line, not the monthly total.

> [!NOTE]
> If one send appears several times and you do not recognise the retries, look for an automatic rule behind it: what runs on its own leaves its trace too, and it is the commonest explanation.

**What if the failure was the platform's?**

That is a different matter: show support the line and it gets reviewed.

**Does cancelling before sending cost anything?**

No: what never went out is not an outward action.

**Does a batch of four hundred count as four hundred?**

No: a bulk send counts as the single action it is.

## Ejemplos

**A company resends a request four times to a mistyped address.**

- Fixes the contact card before the next send and tests the batch with two

→ It lands on the first attempt and the same spend stops repeating over a one-character error.

**An action fails and nobody knows whether it consumed.**

- Checks that activity's breakdown

→ The doubt is settled by the record.

**It is repeated after a failure just in case.**

- Checks the status before repeating

→ Nothing is consumed twice over one failure.

**A process is cut off halfway.**

- Checks what actually ran

→ It resumes from where it was.

**Consumption is disputed over a failed action.**

- Provides that activity's breakdown

→ The dispute is resolved precisely.

**An error repeats and consumes each time.**

- Reviews the cause before retrying

→ The next attempt makes sense.