Glossary

Stripe Credit Note

A Stripe credit note is an object that adjusts the amount of a finalized invoice downward, leaving the original invoice in place, and settles any excess as a refund, a customer balance credit, or a credit recorded outside Stripe.

Also called: cn_, credit note, Stripe invoice credit

Start a free trial View Pricing

Definition

Once a Stripe invoice is finalized, its line items are fixed. You cannot edit it into a smaller number. A credit note is the object Stripe gives you for saying "this invoice was for too much," and it works by adjustment rather than replacement.

That is the distinction that matters for bookkeeping. A void destroys the invoice as a document. A credit note leaves the invoice exactly where it is, at its original amount, and records a separate object that reduces what is owed or returns what was paid. The audit trail keeps both halves: what you billed, and what you credited back.

Stripe describes the operation precisely. A credit note "will first reduce the invoice’s `amount_remaining` (and `amount_due`), but not below zero," and that portion is reported as `pre_payment_amount`. Anything beyond what was still owed becomes `post_payment_amount`, and that part has to go somewhere real, because the customer has already handed over the money.

Key points

+Object ID prefix is `cn_`; its line items are `cnli_`.
+Adjusts a finalized invoice downward without voiding or replacing it.
+`pre_payment_amount` reduces what is still owed; `post_payment_amount` covers money already paid.
+`type` is one of `pre_payment`, `post_payment`, or `mixed`.
+`status` is either `issued` or `void`.
+Optional `reason` is one of `duplicate`, `fraudulent`, `order_change`, or `product_unsatisfactory`.
+Carries line-level tax detail, which is why it is the refund path that keeps tax correct.
+In Acodei, a credit note becomes a QuickBooks Credit Memo.

The split that governs everything: pre_payment and post_payment

Every credit note is measured against how much of the invoice was still outstanding at the moment you issued it.

The part that lands against an unpaid balance is `pre_payment_amount`. It reduces `amount_remaining` and `amount_due`, and Stripe caps it at zero, so a credit note cannot push an invoice into negative territory by this route. Nothing moves. The customer simply owes less.

The part that exceeds what was outstanding is `post_payment_amount`, and it represents money the customer has already paid. Stripe will not let that sit as an abstraction. It must be settled as some combination of three things: a **refund** (create a new one with `refund_amount`, or link existing ones), a **customer balance credit** (`credit_amount`, which Stripe automatically applies to their next invoice when it finalizes), or an **outside of Stripe credit** (`out_of_band_amount`, for money you are returning by other means, such as a bank transfer you will do yourself).

Stripe enforces the arithmetic: the sum of refunds, customer balance credits, and outside of Stripe credits must equal `post_payment_amount`. That constraint is the reason the object is useful to accountants. A credit note is never ambiguous about where the money went.

The `type` field summarises which side it fell on. `pre_payment` means the invoice was still open, `post_payment` means it was already paid, and `mixed` covers a credit note that spans both.

What it is not

**Not a void.** Voiding cancels the invoice as a document. A credit note leaves it standing and records the reduction alongside it. If you need the original billing event to remain visible, which for most accrual bookkeeping you do, the credit note is the correct instrument.

**Not simply a refund.** A refund is a movement of money. A credit note is a document that adjusts an invoice, and it may or may not produce a refund depending on whether any of it falls into `post_payment_amount`. A credit note issued against a wholly unpaid invoice moves no money at all.

**Not one per invoice.** You may issue several against the same invoice. Each one increments the invoice’s `pre_payment_credit_notes_amount`, `post_payment_credit_notes_amount`, or both, depending on what was outstanding when it was created.

One interaction is worth knowing before you mix mechanisms: for invoices that also have refunds created through the Refund API directly, Stripe subtracts those refund amounts from the maximum creditable amount, so the combined credit notes and refunds cannot exceed the invoice amount. If your systems issue both, the ceiling is shared.

Line items, and why tax rides on them

A credit note is built from lines, and each line has a `type` of either `invoice_line_item` or `custom_line_item`. The first points at a specific line on the original invoice via `invoice_line_item`. The second is a free-form amount, and Stripe blocks it when the invoice was set up with `automatic_tax[enabled]=true`, because a custom amount cannot be attributed to anything the tax engine calculated.

That restriction is the whole reason credit notes matter for tax. Because the lines point back at real invoice lines, the credit note carries the tax breakdown with it: `total_taxes` aggregates the tax across lines, and `subtotal_excluding_tax` and `total_excluding_tax` let you separate the goods from the tax on them.

A payment-level refund has none of this. It is an amount against a charge, with no statement about which products it covered or how much of it was tax. Two refunds of the same size can carry completely different tax, and nothing in a plain refund distinguishes them.

This is why the choice of refund mechanism is a bookkeeping decision and not a UI preference. Issue a credit note and the tax portion is knowable. Issue a payment refund and it has to be reconstructed by hand.

Fields worth knowing before you reconcile

The **`status`** is either `issued` or `void`. A voided credit note is not deleted, so a credit note that no longer applies still exists in your data and has to be filtered out.

The **`reason`** is optional and nullable, drawn from `duplicate`, `fraudulent`, `order_change`, and `product_unsatisfactory`. It is the closest thing to a machine-readable explanation of why revenue came back, so it is worth populating even though Stripe does not require it.

The **`number`** is a human-facing document number in its own sequence, formatted like `C9E0C52C-0036-CN-01`, and Stripe generates a **`pdf`** to match. Credit notes are customer-facing documents, not just ledger entries.

**`effective_at`** sets the date the credit note is in effect and replaces the system-generated date of issue printed on the PDF. If you are crediting in one period for something billed in another, this is the field that decides which date the document shows.

**`customer_balance_transaction`** links to the balance movement when the credit went to the customer’s balance rather than back to their card, which is the trail to follow when a later invoice mysteriously bills less than it should.

Stripe also offers a **preview** endpoint that returns what a credit note would look like without creating it. For anything scripted, previewing first is how you find out that your amounts do not add up before you have written an immutable document.

How a Stripe credit note posts to QuickBooks

With Invoice Sync enabled, Acodei listens for `credit_note.created` and creates a **QuickBooks Credit Memo**. It is linked to the previously synced invoice where possible, and where that is not possible it is posted to the customer instead, which leaves the credit sitting on the customer record rather than against a specific invoice.

That fallback is not arbitrary. There is a documented case where a Stripe invoice is paid via a credit note customer balance, and Acodei deliberately does not link the credit note to the invoice in that situation, applying it only to the customer. If you are looking for a credit memo against an invoice and find it on the customer instead, that is the path it took.

Credit notes also change what voiding does. When a Stripe invoice is voided, Acodei either voids the QuickBooks invoice or creates a Credit Memo, and if credit notes are attached to that invoice they are deleted first. The sequence matters because a QuickBooks invoice carrying an applied credit memo cannot simply be voided out from under it.

**On tax, the credit note is the mechanism that makes refunds correct.** Acodei replicates Stripe credit notes in QuickBooks with the correct tax lines, and tax refunds process correctly for users on Advanced Tax Mapping using credit memos. Where a partial refund has line-level breakdown available, as a credit memo does, the partial tax portion is refunded too. A payment refund without line-level detail is the opposite case: Acodei may not be able to determine how much tax was refunded, which can produce discrepancies, and that handling is not implemented. Acodei’s own documentation states the conclusion plainly, that refunds require a credit note to accurately reduce tax in QuickBooks.

One setting underpins all of it. Acodei recommends keeping QuickBooks **Automatic Application** turned on so that payments and credit memos settle invoices automatically. How that application behaves on the QuickBooks side, including when it picks the wrong invoice, belongs to the [QuickBooks credit memo](/glossary/quickbooks-credit-memo) entry.

Invoice Sync is a premium feature, toggled per company in the Acodei dashboard, so credit note syncing follows whether it is enabled for that company.

Want to see this on your own Stripe data?

Start a free trial

Frequently asked questions

What is a Stripe credit note?

An object that adjusts the amount of a finalized invoice downward without voiding it. Stripe first applies it against whatever is still owed, capped at zero, and any excess is settled as a refund, a credit to the customer balance, or a credit recorded outside Stripe.

What is the difference between a credit note and voiding an invoice?

Voiding cancels the invoice as a document. A credit note leaves the original invoice in place at its original amount and records the reduction as a separate object, so both the original billing and the credit remain in the audit trail.

What do pre_payment_amount and post_payment_amount mean?

`pre_payment_amount` is the part of the credit note that reduces the invoice’s outstanding balance, which Stripe will not take below zero. `post_payment_amount` is the excess, representing money the customer already paid, and it has to be settled as refunds, customer balance credits, or credits made outside Stripe that together equal it exactly.

Does a Stripe credit note always create a refund?

No. A credit note against an invoice that is still unpaid moves no money at all; it just reduces what is owed. A refund is only created when the credit note exceeds the outstanding balance and you choose `refund_amount` to settle that excess, rather than a customer balance credit or an out of band credit.

Can I issue more than one credit note for the same invoice?

Yes. Each one increments the invoice’s `pre_payment_credit_notes_amount`, `post_payment_credit_notes_amount`, or both, depending on the invoice’s remaining amount at the time. If you also use the Refund API on the same invoice, Stripe subtracts those refunds from the maximum creditable amount so the combined total cannot exceed the invoice.

Why does a credit note handle tax better than a refund?

Because its lines point back at specific invoice line items, so it carries the line-level tax breakdown. A payment-level refund is just an amount against a charge with no product or tax attribution, so the refunded tax cannot be derived from it.

What does a Stripe credit note become in QuickBooks?

Through Acodei with Invoice Sync enabled, `credit_note.created` produces a QuickBooks Credit Memo, linked to the synced invoice where possible and otherwise posted to the customer.

Why did my credit memo land on the customer instead of the invoice?

Acodei links the credit memo to the invoice where it can. In the documented case where a Stripe invoice is paid via a credit note customer balance, it deliberately does not link the credit note to the invoice and applies it to the customer only, so the credit sits on the customer record.

What happens to credit notes when a Stripe invoice is voided?

Acodei voids the QuickBooks invoice or creates a Credit Memo, and any credit notes attached to that invoice are deleted first. The ordering exists because a QuickBooks invoice with an applied credit memo cannot be voided while the memo is still attached.

What customers say about running Stripe through Acodei

★★★★★

“If you're testing out all the different Stripe/QuickBooks integration apps right now, let me save you some time. This one is the best one by far.”

RyanOwner at Indie Music Academy