> ## Documentation Index > Fetch the complete documentation index at: https://docs.garmentflow.ai/llms.txt > Use this file to discover all available pages before exploring further. # Debit and credit notes > The two adjustment documents the workspace issues on a customer account — a debit note that adds to what the customer owes, a credit note that reduces it — both gated by maker-checker approval before they post to the finance ledger. A **debit note** and a **credit note** are the two adjustment documents finance teams issue on a customer account when a charge needs to be added or reduced outside the normal invoice flow. A debit note adds to what the customer owes; a credit note reduces it. Both are gated by the workspace's [maker-checker approval model](/admin/user-management#maker-checker-approvals) — a draft is prepared, submitted, and reviewed by a second person before the figures hit the customer's account. This page describes what each note is, what it does to a customer balance, the approval lifecycle they share, and the **void-and-reissue** path the workspace uses to correct a note that has already been approved. ## What they are A debit note and a credit note are different in **direction**: one adds, one subtracts. Everything else they share — fields, lifecycle, surface, the reversal-and-reissue mechanic — is identical. * A **debit note** (`DN`) is a charge raised to the customer for something owed back to the workspace: a price correction in the workspace's favour, a rebill on a previously credited item, a missed accessory, a late charge agreed under the contract. Posting it adds to the customer's outstanding balance the same way a customer [invoice](/modules/invoices) does. * A **credit note** (`CN`) is a credit issued to the customer for something owed back to them: a return, a rebate, a price correction in the customer's favour, an agreed allowance. Posting it reduces the customer's outstanding balance — or, where the customer has no open balance, leaves an applied credit on the account. Both notes are **customer-side** documents. The workspace uses them to adjust customer accounts; vendor-side credits are recorded on the relevant vendor invoice and on the [Payables board](/modules/payables) — they do not use the customer DN/CN flow. ## Why they exist A customer invoice covers the agreed price of a shipment or a deposit; it is the bulk of the receivables work. Real customer relationships, though, have a longer tail: a small reconciliation after a season, a goodwill credit, a rework charge agreed weeks after the goods landed. Cutting a new invoice — or, worse, editing the original — would muddle the original billing record. A debit or credit note solves this by being its own document, with its own number, its own date, and its own ledger entry. The original invoice is left untouched; the adjustment reads on the same customer account as a separate row, and the running balance reflects both. ## When they are used Debit and credit notes are issued and managed on the **Offset / Notes (沖帳 / 冲账)** tab inside the [Finance module](/modules/finance) — the same tab the team uses to apply customer deposits against invoices. Both note types live in one **Debit / Credit Notes** list under the tab. Common reasons the team reaches for each: * **Debit note.** A rebill of an accessory cost the customer agreed to reimburse; a freight or duty pass-through the original invoice omitted; a price correction in the workspace's favour after the invoice was agreed. * **Credit note.** A return after a shipment; a rebate the customer qualified for; a small price correction in the customer's favour; a goodwill credit on a future order. ## What appears on the document Both note types carry the same fields: * `Note no.` — the document's own number. Debit notes are numbered in a workspace-wide `DN` series; credit notes in a `CN` series. The pattern follows a year-and-month form (e.g. `DN2506....`, `CN2506....`) so the notes read in order. * `Type` — **Debit** or **Credit**. A note's type is set when it is created and stays with the document; a draft can be discarded, but a debit note cannot be flipped into a credit note in place. * `Customer` — the customer the note is raised against. Required. * `Invoice` — the original customer invoice the note relates to, where one applies. Optional: a standalone adjustment that does not tie back to one invoice can be issued without naming one. * `Issue date` — the date the note is raised; drives the ledger entry's business date. * `Currency` — the document's own currency. * `Amount` — the pre-tax amount in the document's own currency. * `Tax type` and `Tax amount` — the tax classification (taxable domestic, zero-rated export, or tax-free) and the tax figure that goes with it. * `Total amount` — `Amount + Tax amount`. The total is what posts to the ledger when the note is approved. * `Notes` — free text the workspace keeps on the document. ## How a note affects the customer balance A note's effect on the customer's outstanding balance is the same kind of movement an invoice or a receipt makes — written to the receivables side of the [finance ledger](/concepts/finance-ledger), keyed to the document, and visible on every Finance view that reads the ledger: * An **approved debit note** posts a **charge raised** entry on the receivables side. The customer's outstanding balance on the [Receivables board](/modules/receivables) rises by the note's total amount, and the entry surfaces on the [Statement of Account](/modules/statement-of-account) under the `Charge` column with `Debit note` as the entry type. Behind the scenes, a debit note is a charge raised — the same kind of entry a customer invoice produces. * An **approved credit note** posts the opposite movement on the same side. The customer's outstanding balance falls by the note's total amount, and the entry surfaces on the [Statement of Account](/modules/statement-of-account) under the `Receipt` column with `Credit note` as the entry type — the credit note settles against an open balance the same way an applied deposit does. A note that has **not yet been approved** does not post and does not move any figure on Receivables or on the Statement of Account. The note sits on the **Offset / Notes** tab with a draft or pending-approval status until a checker either approves or rejects it. ## The approval lifecycle Every debit and credit note moves through the workspace's standard [maker-checker approval lifecycle](/admin/user-management#the-approval-lifecycle). The states are the ones the rest of the finance approval surfaces use: * **Draft.** The maker is preparing the note. Nothing has posted to the ledger; the customer balance is unchanged. * **Awaiting approval.** The maker has submitted the note. It is visible on the **Approval worklist** under the [Finance module](/modules/finance)'s **Approvals (覆核 / 复核)** tab to every eligible checker — except the submitter themselves. * **Approved.** A checker has approved the note. The **charge raised** movement (debit note) or the offsetting movement (credit note) posts to the ledger; the customer's outstanding balance updates. * **Rejected.** A checker has rejected the note, recording a reason. The note returns to the maker to correct or discard. A rejected note never posts to the ledger. A submitter never approves their own submission; the segregation-of-duties rule applies even to administrators. See [Maker-checker approvals](/admin/user-management#maker-checker-approvals) for the rule itself, the roles permitted in each part, and the worklist mechanics. This page describes *what* the maker-checker flow gates; the rule is canonical there. Each step in the lifecycle is recorded on the note's audit history: **Created**, **Submitted**, **Approved**, **Rejected** — and, where a note is later voided and reissued, **Voided** and **Reissued**. ## Voiding and reissuing a debit or credit note An approved note that turns out to be wrong — a wrong amount, a wrong customer, a wrong tax classification — is **never edited**. The workspace **voids** the original document and **reissues** a replacement in its place. The mechanic is the same one used for customer [invoices](/modules/invoices#voiding-and-reissuing-an-invoice): the original document keeps its number and its place in history; the ledger gains a reversal entry that unwinds the original's effect; a fresh replacement document is created and points back at the one it replaces. ### How the flow runs 1. **Void the original note.** The note is marked **Voided**: the document keeps its number, its lines, its customer, and its issue date, and gains a `Voided at` timestamp, a `Void reason`, and a record of who voided it. The audit history records a **Voided** event. 2. **A reversal entry posts to the ledger.** If the original note had reached **Approved** and posted to the ledger, the reversal posts a new entry of the opposite direction, in the same amount, linked back to the entry it cancels. The customer's outstanding balance returns to where it would have been if the note had never been approved. A note voided before it was approved had not posted in the first place, so no reversal entry is written — only the document changes state. 3. **Reissue a replacement note.** A fresh note is created in **Draft**, pointing back at the original through a `Reissued from` link. The replacement carries its own new note number and its own issue date; the amount and tax type can be amended to the corrected figures on the way through. The reissued note enters the same approval lifecycle from the top — Draft → Awaiting approval → Approved — and only posts to the ledger when a checker approves it. The chain reads end-to-end on the document audit history: a **Voided** event on the original, a **Reissued** event linking to the successor, and a **Created** event on the successor pointing back. A note that has been voided cannot be voided again. A draft or awaiting-approval note that is no longer needed is voided too — the document's place in the audit history is kept, even though no ledger entry needed reversing. ### "Void" vs "reversal entry" — the boundary This is the page where the workspace's two correction concepts are defined side by side: * **Void** is a **document-level action** the user takes on a note (or on a customer [invoice](/modules/invoices)). The note is marked voided; the document's status, its `Voided at` timestamp, its `Void reason`, and the user who voided it are recorded on the document itself. Voiding is the action; the document is the subject. * A **reversal entry** is the **ledger-level entry** the workspace writes when a void commits on a note that had already posted to the ledger. It is a new entry on the [finance ledger](/concepts/finance-ledger) with the opposite direction of the original, the same amount, and a link back to the entry it cancels. The reversal entry is how the ledger's no-edit, no-delete rule is honoured every time the workspace corrects a previously posted figure. The two work together — voiding an approved note produces a reversal entry on the ledger — but they sit at different layers and the docs name them differently on purpose. A reader who needs to cancel a document reaches for a void; a reader who needs to understand why a balance has two ledger entries with the same number reads the reversal-entry rule on [the finance ledger](/concepts/finance-ledger). ## Foreign currency A debit or credit note is issued in the document's own currency. When the note posts to the ledger, the entry carries the amount in the note's currency and the equivalent in the workspace's reporting currency at the rate in effect on the issue date — the same rule that applies to a [customer invoice](/modules/invoices). The customer's per-currency balance moves by the note's total; balances in other currencies are untouched. ## Who can act on debit and credit notes The roles permitted in each part of the lifecycle are set by the workspace's [maker-checker approval model](/admin/user-management#who-plays-which-part): * **Maker** (creates, submits, voids and reissues): Finance, Finance checker, Administrator. * **Checker** (approves or rejects): Finance checker, Administrator. A Finance checker or an Administrator can submit a note of their own, but on a note they submitted they are the maker — they cannot then approve it. The rule applies by user identity, not by role. ## Where they sit in the workflow * **Upstream.** A debit or credit note is raised against a customer — and, usually, against a specific customer [invoice](/modules/invoices) — to adjust a charge that has already been billed or to record a charge that was missed. * **Across.** The note is prepared and approved on the [Finance module](/modules/finance)'s **Offset / Notes** tab; pending notes appear on the **Approvals (覆核 / 复核)** tab and on a checker's approval worklist. * **Downstream.** An approved note posts to the [finance ledger](/concepts/finance-ledger); the [Receivables board](/modules/receivables) and the [Statement of Account](/modules/statement-of-account) read off the same ledger entries. ## Related pages * [Finance module](/modules/finance) * [Invoices](/modules/invoices) * [The finance ledger](/concepts/finance-ledger) * [Receivables](/modules/receivables) * [Statement of Account](/modules/statement-of-account) * [Maker-checker approvals](/admin/user-management#maker-checker-approvals)