Invoicing Stripe Payments in Portugal: Payments, Subscriptions and Refunds

Stripe issues invoices and receipts that look impeccable. None of them is a Portuguese tax document. No ATCUD, no series filed with the tax authority, nothing entering your SAF-T file, and Stripe is not certified software.

Selling through Stripe from Portugal always means two layers: the payment, which lives in Stripe, and the tax document, which has to be born in certified software. This guide is about connecting the two without losing anything on the way.

The path of a payment

From Stripe to Certified software: what gets decided on the way.

The three ways to charge, and why they matter

Stripe has more than one way to take money, and each carries different information about the sale. That is why poorly built integrations work in one case and fail in another.

| How you charge | What Stripe creates | What that carries | |---|---|---| | Payment Link / Checkout | A Session and a PaymentIntent | The buyer and the amount; the lines come from the session | | Subscription | An Invoice per period, and its payment | Lines, periods and discounts, the richest source | | Direct API charge | A PaymentIntent on its own | Only the amount: the lines are yours to supply |

A subscription billed monthly brings one Invoice a month, with the right periods. A one-off charge brings none of that. If the integration only knows how to read one of these shapes, half the sales go uninvoiced or come out with a generic line.

The total is whatever was paid

A rule with no exceptions: the document total has to equal what was actually paid.

It sounds obvious and it is where most documents go wrong, because the temptation is to add up the lines and trust the sum. It does not hold: discounts, rounding, coupons, tax calculated by Stripe and currency conversion all make the sum of the lines and the amount charged diverge by cents.

The source of truth is the payment processor, not the arithmetic of the lines. One cent is enough to break bank reconciliation and to cost somebody a morning in January.

The document date

The invoice date is the payment date, not the date the integration ran.

This matters most for payments that take time: SEPA Direct Debit confirms days after it starts, and invoicing with today's date when the money arrived three days ago puts the sale in the wrong period. At month end, in the wrong month.

Mind the series rule too: a series will not accept a document dated earlier than the last one issued in it. Back-dated invoicing means planning the order of issue.

Foreign currency

You charge in dollars; the Portuguese document has to be in euros, or at least carry the euro amount and the exchange rate used.

The rate is not one you pick: it is the official rate applicable on the date of the transaction, and the ECB reference rate is the usual criterion. Stripe has its own rate for converting what it pays out to you. They are different things and it is normal for them not to match to the cent.

Who the buyer is

Stripe does not always know who bought. A Payment Link with no billing fields gives you an email address and nothing else.

For the tax document, that gets resolved in one of two ways:

• With a VAT number, which the customer has to provide somewhere: a checkout field, the Stripe Customer, or metadata.
• Without one, issuing to a final consumer, within the limits of a simplified invoice.

What you should not do is invent a customer record from the email and leave it incomplete: the certified software fills up with hundreds of duplicate customers, and correcting the VAT number later means editing the customer record, not the document already issued.

Subscriptions: the cases that break integrations

• The first charge arrives one way and the rest another. Listening only to the checkout session event invoices the first month and loses the rest; listening only to the paid invoice can duplicate the first.
• Trials. A free period produces a €0 invoice. Issuing a €0 tax document is rarely what anyone wants.
• Mid-cycle changes. Upgrades and downgrades produce proration lines, with negative amounts. A negative line is not acceptable in every certified package.
• Invoices with many lines. Stripe does not hand over every line at once: it hands over the first ones and says there are more. An integration that does not fetch the rest issues incomplete invoices, and the total stops matching.

Refunds

A refund in Stripe returns money and undoes no document. On the tax side you need a credit note:

• Partial refund: the credit note carries the returned lines.
• Full refund: it mirrors the whole document.

If the refund is for a sale that was never invoiced, there is nothing to credit: there is a sale that stopped existing.

Stripe Tax

Stripe Tax calculates tax by country and solves much of the rate problem. It does not solve the rest: it still does not issue a certified document, it does not handle the Portuguese exemption code, and it does not do reverse charge with VIES validation on the document side.

And there is a detail that bites: if Stripe Tax is switched off, payments arrive with no tax at all. Your integration then has to decide the rate, and an integration that assumes "tax always comes with it" issues everything at 0% without raising a single error.

How Rioko helps

Rioko listens to Stripe's events and treats the three ways of charging the same way: one-off payment, checkout session and subscription invoice all come down the same path and come out as a certified document in InvoiceXpress, Moloni or Vendus.

What is in there because it hurt at some point:

• The total comes from the payment, always, and issuing is refused when it does not match what was about to be issued.
• The date is the payment date, including on SEPA, where the gap is days.
• The lines are paginated to the last one, even when a Stripe invoice has dozens.
• A payment is invoiced once, even with repeated events, and Stripe does repeat them.

If you also sell through a shop, the path is the same: Invoicing Shopify orders in Portugal.

Connect your Stripe account →