The Credit Note: Correcting an Invoice That Has Already Been Sent
An invoice is the one document in a small firm that everybody expects to stay still. It is sent, filed, forwarded to the accountant, and then someone notices the wrong quantity, a discount that was never applied, or a project that was cancelled halfway. At that moment the instinct is to open the invoice and correct it. Firmspace CRM does not let you rewrite a document that has already left the building. It offers the quieter, more durable answer: a credit note.
A credit note is a separate document in the same invoices list, not a mode of the original. It gets its own number from its own sequence, it is linked to the invoice it corrects, and the original keeps its number, its date and its contents. In the list it carries a small chip that says what it is, and a line that names the source invoice. Anyone opening the file later sees two documents and a clear relationship between them, not one document that changed its story.
The button appears only where the correction makes sense. The invoice must be a real invoice, not a quote, an order or another credit note, and it must be sent, paid or overdue. A draft is deliberately excluded: it has not reached the customer yet, so it can simply be edited. This is not a technical restriction for its own sake. It follows the moment when the number becomes part of the customer's records.
What the dialog asks for is modest: one field, an internal note up to two thousand characters. The amount is not typed again. By default the credit note copies the customer, the address, the tax number, the contact person, the company, the deal, the order, the contract, the currency and the line items of the source invoice, and reverses the full amount. The hint above the field says it plainly: the invoice itself keeps its number and is not changed.
That default is a full reversal, and the interface does not offer a partial one. The API behind it accepts its own line items, so a developer can issue a reduced credit, but an accountant working in the browser presses one button and gets the whole amount back. It is better to know this before the first correction than to discover it while a customer waits for a corrected document.
Why not simply delete the invoice? The assistant can delete an invoice, including a paid one, and the full snapshot stays in the audit log. That path exists for test records and genuine mistakes in the CRM, not for bookkeeping. A deleted invoice disappears from the list the customer was told about, while a credit note leaves both halves of the story visible: what was charged and what was reversed.
The number deserves its own paragraph, because it is where corrections usually go wrong. The credit note never borrows the invoice's number and never continues the invoice sequence. It has a separate counter and a separate prefix, GS by default, which the firm can change in the finance settings, and an active document template can override it. So the invoices stay RE-2026-1, RE-2026-2, and the credit notes run GS-2026-1, GS-2026-2.
Fiscalisation is the part most firms discover late. In Ukraine, if the original invoice had a fiscal receipt and automatic fiscalisation is switched on, issuing a credit note also issues a return receipt that points at the sale receipt. If that second call fails, the failure is written onto the credit note itself and the credit note is still issued. The money movement is not silently rolled back because a fiscal endpoint was unavailable.
The rest of the CRM reacts as it would to any other document. A document event appears in the activity history of the deal, the contact and the company, the audit log records who issued the credit note and for which invoice, and an automation rule can start from the event invoice_credit_note_created. That is how a firm can tell the accountant, open a task to check the stock return, or post a message to the team feed without anyone remembering to do it.
One date rule is worth stating. The credit note is dated with today, not with the date of the original invoice, and it has no due date at all, because nobody is expected to pay it. If today falls inside a closed accounting period, the request is refused instead of quietly writing into a month that has already been reported. The correction then belongs to the open period, which is exactly where an accountant wants it.
The reporting side is equally deliberate. The VAT return, the income-surplus statement and the BWA select credit notes together with invoices, and the credit note is counted in the period of its own issue date. A correction made in October therefore belongs to October, not to the August invoice it corrects. That is the honest way to read a period: what was actually reversed in it.
Now the AI boundary, because it explains the whole design. The assistant in Firmspace can create invoices, quotes, orders and contracts, send an invoice, mark it paid in full or in part, change dates or notes, and even delete a document with confirmation and an audit snapshot. It has no tool for issuing a credit note. The correction is left to a person on purpose: it is a decision with accounting consequences, and the product does not hand it to a model that cannot see the customer's file.
A practical routine looks like this. Open the invoice, check that it is the right one, decide whether the whole amount must go back, write the reason in the note in language your accountant will understand, issue the credit note, download the PDF and send it to the customer the way you send any other document, then let the feed and the automation carry the news to the team. The original stays where it was. Two documents, one clear story.
Corrections are not an exception in business; they are part of the process. The difference between a calm month-end and a painful one is rarely the number of mistakes. It is whether the paper trail still makes sense after them. A separate numbered document that points at the invoice it reverses is the least dramatic way to keep that trail intact.