# Connection settings

Per-connection settings that affect how BeeL. processes Stripe payments — fiscal limits, customer creation, email delivery.

Each Stripe connection has its own configuration. You can have a strict production connection, a permissive staging connection, and a third one for a different revenue stream — all on the same BeeL. account. This page lists every setting that affects how BeeL. turns a Stripe payment into an invoice.

<Callout type="info">
  **Dashboard or API.** Configure them at **Settings → Integrations → Stripe → pick connection**, or programmatically: [List payment connections](/payment-connections/listCompanyPaymentConnections) returns each connection with its settings, and [Update a payment connection](/payment-connections/updateCompanyPaymentConnection) changes them. Settings this page describes that are not in those operations are dashboard-only.
</Callout>

## At a glance

| | |
|---|---|
| **Where to configure** | Settings → Integrations → Stripe → pick connection |
| **Independent per connection** | Yes — multiple Stripe accounts can have different settings |
| **Changes affect** | Only new invoices; already-issued invoices are immutable |
| **Most-tuned settings** | Auto-create customer, auto-send via email |

## Fiscal limits

### Simplified threshold (deprecated)

<Callout type="warn">
  **Deprecated: this setting no longer affects which invoice BeeL. generates.** A customer with full fiscal data (NIF + address) always gets a standard invoice (F1), whatever the amount. The API field `simplificada_threshold` is still accepted and returned, and it is still validated (between 0.01 € and 3,000 €), so existing integrations keep working, but its value is ignored. You can stop sending it.
</Callout>

| | |
|---|---|
| **API field** | `simplificada_threshold` (deprecated) |
| **Default** | 400 € |
| **Range accepted** | 0.01 € to 3,000 € |
| **Effect** | None |

Before, a charge below the threshold was issued as a simplified invoice (F2) even when the customer had given a NIF and address. That no longer happens: the invoice type now depends only on the customer's data.

- **Customer with a NIF (or foreign identifier) and a complete address** — standard invoice, at any amount.
- **Customer without full fiscal data** — simplified invoice up to 3,000 €. Above that amount a simplified invoice is not allowed, so BeeL. saves a draft (and, on Live connections, emails you); it appears in **Needs attention** (*Necesita atención* in the dashboard) for you to complete and issue. See [Charges that cannot be invoiced automatically](/stripe/generated-invoices#charges-that-cannot-be-invoiced-automatically).

A simplified invoice generated from a payment **never identifies its recipient**: it keeps the name, email and address the payment carries, but not the NIF or `alternative_id`, and it is not linked to the customer. It is the same rule as for invoices you create through the API — see [Simplified vs standard](/verifactu/simplified-vs-standard). It applies to a customer without full fiscal data, to a customer with a NIF but no address, and when a standard invoice goes to your simplified series because the connection has no default standard series (only up to 3,000 €). The full F1/F2 decision tree is in [Generated invoices](/stripe/generated-invoices#forward-invoices-standard-vs-simplified).

### Prices include tax

When Stripe Tax is **not enabled** on the connection, BeeL. needs to know whether the Stripe charge amount already includes IVA.

| | |
|---|---|
| **Default** | On (charges are inclusive) |
| **On** | BeeL. treats the charge total as inclusive: `base = total / (1 + rate/100)` |
| **Off** | BeeL. treats the charge total as the base and adds IVA on top — the resulting invoice total is **larger** than what Stripe charged |

When Stripe Tax IS enabled, this setting is ignored (Stripe's breakdown wins). See [Data conversion](/stripe/data-conversion).

<Callout type="warn">
  **Turn this off only if your Stripe prices are net.** Most B2C prices in Stripe are tax-inclusive; turning it off on inclusive prices produces invoices whose total exceeds what the customer paid.
</Callout>

## VeriFactu submission

There is no per-connection VeriFactu setting. Whether a Stripe-generated invoice reaches AEAT is decided by the issuing NIF, like any other invoice — see [VeriFactu submission for Stripe invoices](/stripe/verifactu-submission).

## Customer management

### Auto-create customer

| | |
|---|---|
| **Default** | On |
| **Effect when on** | BeeL. stores a mapping for each new Stripe customer and auto-links to a managed customer when NIFs match |
| **Effect when off** | Invoices are issued with the buyer's data inline; nothing is stored for re-use |

See [Customer mappings](/stripe/customer-mappings).

## Invoice delivery

### Auto-invoicing

| | |
|---|---|
| **Default** | On in Test mode. **Off in Live mode**: you switch it on yourself |
| **Effect when on** | Payment-success events generate invoices |
| **Effect when off** | Events are received but no invoice is created (useful for staging, migration, or pause windows) |

A Live connection starts with auto-invoicing off, because every charge it invoices produces a real invoice. Until you switch it on, no charge is invoiced and nothing warns you. Switch it on in the dashboard or with `auto_invoice_enabled` ([Update a payment connection](/payment-connections/updateCompanyPaymentConnection)). Charges received before that are not invoiced on their own: [retry them](/stripe/edge-cases-and-limits#retrying-a-stripe-event) once it is on. Disconnecting and reconnecting the account keeps the value you chose.

When off, events are recorded as skipped without asking for attention, and can be retried once you turn auto-invoicing back on — see [Edge cases and limits](/stripe/edge-cases-and-limits#retrying-a-stripe-event). API field: `auto_invoice_enabled`.

### Event source

A Stripe account sends every event to the same webhook endpoint, but you may only want one family of them invoiced. API field: `event_source`.

| Value | What gets invoiced |
|---|---|
| `BOTH` (default) | Charges and Stripe Invoices. A charge that arrives through both families is invoiced once |
| `PAYMENTS` | Charges, from `payment_intent.*` and `checkout.session.*`. `invoice.*` events are ignored |
| `INVOICES` | Stripe Billing documents, from `invoice.*`. `payment_intent.*` and `checkout.session.*` events are ignored |

Events outside the chosen family are recorded as skipped on purpose and need no attention. Refunds, disputes and credit notes are acted on under every value, because Stripe does not always report a correction through the family the charge came in; a correction whose charge was never invoiced is recorded as skipped and needs no action either. Changing the value affects events that arrive from then on; events already recorded keep their outcome.

### Auto-send via email

| | |
|---|---|
| **Default** | On in Test mode, off in Live mode |
| **Effect when on** | Generated invoices are automatically emailed to the customer (using the email from the Stripe payload) |
| **Effect when off** | Invoices are generated but NOT auto-emailed |

You can always send an issued invoice manually later — that path goes through the public Invoicing API.

## Refund mapping (not configurable)

The `refund.reason` and `credit_note.reason` from Stripe are mapped to AEAT R1–R5 codes by a fixed rule, not a per-connection setting — see [Generated invoices > Mapping Stripe's reason](/stripe/generated-invoices#mapping-stripes-reason-to-r1r5).

## What changes when you flip a setting

| Setting changed | Affects next Stripe event? | Affects existing invoices? |
|---|---|---|
| Simplified threshold (deprecated) | No — ignored | No |
| Auto-create customer | Yes | No (existing mappings stay as they are) |
| Auto-invoicing | Yes | No |
| Auto-send via email | Yes | No (already-sent emails are not re-sent) |
| Prices include tax | Yes (fallback path only) | No |

## Related

<Related>

- [Generated invoices](/stripe/generated-invoices) — how settings affect the F1/F2 + R1–R5 decisions
- [Customer mappings](/stripe/customer-mappings) — auto-create / linked vs ad-hoc
- [VeriFactu submission](/stripe/verifactu-submission) — why there is no per-connection switch
- [How taxes are applied](/stripe/configuracion-impuestos) — the Fiscal Mirror rule

</Related>

---

Full OpenAPI spec: https://docs.beel.es/api/openapi