SaaS

The billing contact: who gets the invoice, the failed-payment email and the renewal notice at a small SaaS's business customers

November 6, 2026

When the card holder is not the user, Stripe, Chargebee and Paddle send billing mail to one address. What each can add, a failed annual renewal day by day, PO and net-30 handling, and a worked churn model with the arithmetic.

A person typing on a laptop at a table in a bright office

A company signs up for your product with a 25-seat plan. The person who clicked through the trial, Dana, types her own work address into checkout and pays with the company card that finance gave her for software. Eleven months later Dana moves to another team and her mailbox is closed. The card is reissued after a fraud alert. Your renewal charge fails, Stripe emails the failure to Dana's old address, and nobody at the customer's company hears about it. Two weeks later the subscription is cancelled. The customer did not decide to leave. Nobody was ever told there was a decision to make.

That is a billing-contact problem, and it is quiet because it shows up in your numbers as ordinary churn. This article sets out where each billing system actually sends invoices, failed-payment emails and renewal notices, what the Stripe API can and cannot change, how purchase orders and net-30 requests from small buyers fit, and what a missing billing contact costs in a worked model for a small SaaS. The Dana story is an illustration we constructed, not a customer case.

Four addresses, and only one of them reads the invoice

Every billing system has some version of the same split: the person who uses the product, the person who bought it, the person whose card is charged, and the person in finance who files the invoice. A small SaaS usually stores one email for all four. The table shows what the three common systems do about the rest, from their own documentation.

text

System      Where billing email goes by default        Extra recipients
----------  -----------------------------------------  ---------------------------------------------
Stripe      Customer email (the account email)         Dashboard only: untick "Same as account email"
            on every Billing email, incl. receipts      to set the To line, "Emails to CC" for more.
                                                        The API does not support adding recipients.
Chargebee   Customer email gets all event               Billing contacts (a checkbox on an extra
            notifications                               contact) receive invoices and payment-related
                                                        invoices; account contacts get subscription
                                                        invoices. Receipt emails to billing contacts
                                                        are a switch you turn on.
Paddle      The buyer who checked out                   One vendor's help centre (CrashPlan) says
                                                        Paddle cannot add extra recipients to a
                                                        subscription; the payer forwards mail. Paddle's
                                                        own docs do not list a field for it.

The Stripe row matters most because most small SaaS companies use it. If you create customers through the API, which is how a self-serve product does it, there is no field for a finance copy. The invoice email goes to customer.email, and that is also the address on the card receipt. Either you ask the buyer for a finance address and store it as the customer email, or you keep a billing contact in your own database and send the important emails yourself. Both are covered below.

What gets sent, to whom, and when

These are the Stripe Billing notifications that matter for a business customer, with the timing Stripe documents. They all go to the same address unless you changed the Dashboard fields above.

text

Email                       Trigger and timing (Stripe documentation)
--------------------------  -----------------------------------------------------------
Expiring card               1 month before the default card expires
Renewal reminder            Before the period ends, by the days you set under "Upcoming
                            renewal events". Only for charge_automatically subscriptions;
                            never for send_invoice ones
Failed payment              After each failed attempt, with a link to update the card
                            (link is omitted when the subscription is send_invoice)
Retries                     Smart Retries default for new accounts: up to 8 tries in 2 weeks
Hard declines               Stolen, lost, incorrect number, authentication required and
                            others are not retried until a new payment method arrives
After the last retry        Your setting: cancel, mark unpaid, leave past_due, or pause
Trial ending                Optional reminder 7 days before the trial ends
Hosted-page link validity   Dies when the subscription is cancelled, goes unpaid, or the
                            renewal period expires

Read the third line twice. A failed-payment email is the only notice that a payment failed, and the recovery link inside it stops working once the subscription is cancelled or unpaid. If it went to a closed mailbox, the retries run, the card is declined again because it was reissued, and the cancellation happens on schedule. In Stripe's sandbox these emails only go to a confirmed team-member address, so delivery to a real finance address is something you confirm by asking the customer.

A failed annual renewal, day by day

Take a card-paid annual plan with Smart Retries on the default 8 tries in 2 weeks, expiring-card email on, and the renewal reminder set to 7 days. The card was reissued 20 days before renewal. This is our timeline built from the documented rules, not a measured trace.

text

Day  Event                                       Who can act on it
---  ------------------------------------------  --------------------------------------
-30  Expiring-card email (card on file expires)  Customer email only
 -7  Renewal reminder                            Customer email only
  0  Renewal charge declined, failure email 1    Customer email only
 1-14 Up to 7 more retries; each failure emails  Customer email only; hard decline codes
                                                 stop the retry until a card is added
 14  Retries end, subscription cancelled         You see it as churn
      (if that is your setting)

Two advance notices and up to eight failure emails, all to one address. If that address is dead, the customer gets zero chances. A note from the Stripe retry page that is easy to miss: when you update the card after a failure, update the field that failed. If the subscription has its own default_payment_method and you only change the customer's default, Stripe keeps retrying the old card.

Card or invoice, by plan size

We could not find a published dataset that splits card against invoice payment by plan size for small SaaS, and the large benchmarks we checked do not break results out by price. Baremetrics' May 2026 summary of 119 US B2B SaaS companies, for example, reports a median attempted recovery rate of 12.7% across 123,810 dunning emails but no plan-size split, and it describes itself as a sample of its own customers. So the rule below is ours, based on how the billing systems behave, not an industry statistic.

text

Annual contract   Collect by        Why                                     Billing contact needed?
----------------  ---------------  --------------------------------------  -----------------------
Under $1,000      Card, automatic  Buyer is usually the user; a card is    Collect it, optional
                                   the paying habit                        
$1,000-$5,000     Card, automatic  A card holder who is not the user is    Yes, at checkout
                  (invoice if      common; finance wants the invoice
                  asked)           copy
$5,000-$25,000    Offer invoice    PO, net terms and bank transfer are     Required: name, email,
                  (send_invoice)   normal requests; card limits get hit    PO yes/no, tax ID
Over $25,000      Invoice, signed  Procurement drives it; the order form   Required, plus AP
                  order form       holds the terms                         portal if they have one

The thresholds are a judgement call. Where card limits and approval rules cut in varies by company, so use the table as a starting point and move the lines when your own refusals tell you to.

Purchase orders and net-30 from a small buyer

A ten-person buyer asking for a PO and net-30 is not trying to be difficult; their bookkeeper pays only against an invoice that cites an order number. Stripe covers this in four places, all documented.

text

Need                    Stripe setting
----------------------  --------------------------------------------------------------
Pay later               collection_method=send_invoice with days_until_due (30) or
                        a due_date. Renewal reminder emails are not sent for these
PO number on invoice    Custom fields: up to four key-value pairs in the invoice
                        header, e.g. {name: "PO number", value: "4500012345"}.
                        Set on the customer, they copy to every new draft; they can
                        be edited on a draft but not after the invoice finalises
Tax ID on invoice       Add the buyer's tax ID to the customer; it prints on the PDF
Reminders if unpaid     "Send reminders if a recurring invoice hasn't been paid":
                        before, on or after the due date, from a preset list

Two traps. First, the custom field is frozen once the invoice is finalised, so a PO that arrives after you send the invoice means voiding and re-issuing, or crediting. Collect the PO number before the first invoice and ask for the next one when the old one runs out. Second, a buyer on net-30 does not get the failure emails or the card-update link, because those belong to automatic collection. Their equivalent is the unpaid-invoice reminder, and it also goes to the customer email.

What a missing billing contact costs: a worked model

Assume a SaaS with 150 business customers at an average of $2,400 a year, billed annually by card, so $360,000 in annual recurring revenue. Each year some renewal charges fail. Two assumptions are ours: when the email reaches someone who handles billing, 70% of failed renewals are recovered; when it reaches nobody, 15% are, because a few customers notice from the product itself. Published recovery rates range widely with how they are defined, so treat 70% and 15% as a stress test, not a forecast. The table gives the extra ARR lost against a world where every notice lands.

text

Failed renewals     Share of customers whose billing email reaches nobody
per year            10%          25%          40%
------------------  -----------  -----------  -----------
3% (4.5 charges)    $594         $1,485       $2,376
6% (9.0 charges)    $1,188       $2,970       $4,752
9% (13.5 charges)   $1,782       $4,455       $7,128

The figure in each cell is failed charges x share unreachable x (70% - 15%) x $2,400. One cell by hand: 9.0 failed charges x 25% unreachable = 2.25 charges; recovery drops from 70% to 15%, so 2.25 x 0.55 = 1.24 customers lost; at $2,400 that is $2,970. It is small next to $360,000, which is why nobody chases it. But it recurs every year, each lost customer takes their expansion with them, and the fix costs one form field. At the high end, 13.5 failures and 40% unreachable, you lose about 3 customers a year purely from addressing.

If your own failure rate is higher, scale the table linearly. Baremetrics repeats a figure that subscription businesses lose about 9% of recurring revenue to failed payments, but it gives no date or method for it, so check your own invoice.payment_failed events for the last 12 months before using it.

What to collect and what to do with it

At checkout or first invoice

Ask for four things next to the card: a billing contact name, a billing email that is not necessarily the user, whether the buyer needs a PO number and an optional tax ID. Label the email field "Where should invoices and payment notices go?" That wording gets finance addresses; "Billing email" often gets the user's own.

If you use the Stripe API

Because the API cannot add CC recipients to Billing emails, pick one of two designs. The simple one is to store the finance address in customer.email and keep the user's address in your own user table. The flexible one is to keep a billing_contacts table of your own and listen for invoice.payment_failed, then send your own email to every contact. Stripe notes that you can turn off its finalised-invoice emails and send your own from webhooks; keep the webhooks running either way.

text

# invoice.payment_failed handler, sketch
def on_payment_failed(invoice):
    customer = invoice["customer"]
    contacts = billing_contacts_for(customer)      # your table: finance + owner
    attempt  = invoice["attempt_count"]            # 1..8 with the default schedule
    link     = portal_session_url(customer)        # billing portal, card update
    for c in contacts:
        send_email(c, subject=f"Payment failed (attempt {attempt}): update your card",
                   body=f"Update your card here: {link}")
    if attempt >= 3:
        notify_account_owner(customer)             # a human on your side

Every quarter

Look for customers whose billing email bounced or belongs to a person who left. Stripe keeps email logs for 60 days on the customer page, updated daily and excluding the current day, which is enough to spot a bounce pattern around a renewal. Sort the list of upcoming annual renewals by days remaining and send a plain email, from a person, to anything inside 45 days whose email you cannot confirm.

The same hygiene helps the exit conversation: when a customer does cancel, the questions in Why they cancelled separate a decision from a mailbox. Annual contracts raise the stakes of one missed email, which is a point against over-discounting them; see Annual or monthly. And if the customer paid with someone else's card and a dispute follows, Chargebacks at a small SaaS covers what to send.

Model a monthly and an annual offer over 12 months: cash collected, revenue recognised and the balance owed if a renewal slips. Use it to see how much one missed renewal email can cost on the plan you sell.

Open the annual discount calculator

Sources

Stripe documentation, read 7 November 2026: Send customer emails (additional recipients, Dashboard only; email logs 60 days), Automate customer emails (expiring cards 1 month before, renewal reminders only for charge_automatically), Automate payment retries (8 retries in 2 weeks, hard declines, payment method order), Customize invoices (four custom fields, PO numbers, tax IDs).

Chargebee: Billing email vs billing contact. Paddle: CrashPlan help centre, additional recipients (a third party's statement about Paddle; we could not read Paddle's own page) and Paddle's list of customer emails. Benchmarks: Baremetrics subscription payment recovery benchmarks, May 2026, 119 companies (vendor sample). The card-or-invoice thresholds and the 70% and 15% recovery rates are our assumptions.