The Credit Note That Crossed the Year

The audit senior arrives on a Tuesday in January with a laptop and a printed request list. Item seven runs to three lines. First, the complete sequence of sales invoice numbers issued during the year, with an explanation for any number that is missing or cancelled. Second, every credit note raised after the year-end against an invoice dated before it, with the reason and the person who approved it. Third, any change to the price or discount on an invoice after it was issued, with who made it and when. The finance manager reads it twice. The first item is a spreadsheet job. The second means finding out what was given back in January for sales booked in December. The third is the one nobody has ever been asked before, and the honest answer depends entirely on what the system allows.

Why an auditor asks these three together

Revenue cut-off is one of the risks an auditor is required to test, and these three requests close the routes by which revenue moves between years. A missing invoice number might be a sale that was raised, delivered and then made to disappear. A credit note in January against a December invoice might be an ordinary return, or it might mean the December sale was never really a sale and was booked to hit a target. A price changed after issue means the document the customer holds and the figure in the books can disagree, and nobody would know which was right.

Request one: the sequence

Start with when a number is given. An invoice takes its number at the moment it is first saved, as a draft, not when it is approved. The counter is locked while the number is taken and the number is written in the same database transaction as the invoice, so two people saving at once never receive the same number, and a save that fails releases the number it was about to use instead of leaving a hole. Numbers run per organization, per document type and per year, in the form INV, the year, then six digits.

Then what can happen to a numbered invoice. It cannot be deleted. The delete action on the web and in the API both refuse with the same message: cancel it if it has not been fulfilled, or raise a credit note. So every number taken is still a row in the register with a status beside it, and the statuses are what you hand the auditor instead of an explanation from memory.

To pull the sequence, filter the invoice register by status if you need to and export it as CSV. The export carries the number, customer, invoice date, total, balance and status. One thing to know: the export honours the status filter and not the date range on screen, so it gives you every invoice in your workspace and you cut it to the year in the spreadsheet. Sort by number, and any break in the run is a question to answer.

The year in the number is the year it was raised

This is the detail most worth knowing before the auditor spots it. The year inside an invoice number is the calendar year in which the invoice was first saved, taken from the system clock. It is not the invoice date, which is typed by whoever raises the draft and can be any date, and it is not your financial year.

That makes the number a cut-off tell. An invoice numbered INV-2027-000004 with an invoice date of 30 December 2026 was raised in January and dated back into the old year. It may be honest paperwork catching up after the holiday, or a January sale pulled into December. Either way it is the first list an auditor will build, and you can build it first by filtering the register to the last weeks of the year and reading the year in each number. If your financial year does not end in December, the same test still works, because the number records when the invoice was keyed rather than which year it claims to belong to.

The ledger date matters too, and it differs by the kind of invoice. An invoice made only of services books its revenue when it is approved, dated on its invoice date if that month is still open. An invoice with stock lines books its revenue when the goods are issued from the warehouse, dated the day they go. So a stock invoice dated 30 December whose goods are checked out on 3 January is January revenue in the books, whatever the date on the document says. That is usually the right answer for goods, and it is worth being able to explain.

Who cancelled it, and why

Cancellation is narrow. It needs the permission to edit invoices, and it is refused once any payment is recorded against the invoice or once the goods have been checked out against it. After that point the only correction is a credit note. A cancelled invoice keeps its number, its customer, its lines and its totals; its balance goes to zero and its status to cancelled.

The invoice itself records the cancellation in its notes: the date and time, and the number of the user who did it. The name sits in the audit log, which records every change made by a signed-in user, on the web or through the app, with their name, email address, IP address and the time. That log is hash-chained: each entry carries a fingerprint of the one before it, an administrator can verify the chain from the audit log screen, and there is no delete route. Entries leave only under the retention policy, and the purge records itself. The details are on the audit trail integrity page.

Two things the auditor will want that you will have to supply yourself. The first is the reason: cancelling asks for none, so the why lives in an email or a person’s memory. The second is the approval. Cancelling clears the approver and approval time from the invoice record, so a cancelled invoice no longer shows who approved it before it was withdrawn. The approval itself is still in the audit log against that invoice, and that is where to point the auditor. The ledger keeps its own record too: if the invoice had booked revenue, cancelling posts a reversing entry, dated the day of the cancellation. A December invoice cancelled in January is reversed in January.

A number that cannot be deleted is only half an answer. The other half is a sentence saying why it was withdrawn.

Request two: credits after year-end

A credit note takes its own number from its own series, and its issue date is the day it is raised. There is no date field to fill in, so a credit note cannot be backdated into a closed year. It can be raised against a named invoice and applied straight away, or raised against the customer and applied later. Raising one needs the permission to manage sales; there is no separate approval step and no amount above which a second person must agree. The reason field is optional and holds a single line.

The ledger side is what an auditor tests. Applying a credit note posts the reversal on the day it is applied: the receivable comes down by the full amount, and revenue and output tax come down in the original invoice’s own proportions, because a credit note carries one amount and no lines. A credit note that has been raised and not yet applied has posted nothing at all. That matters at year-end, because an unapplied credit is a liability the ledger has not recognised yet.

One case surprises people. A credit note is applied in full or refused: if it is larger than the invoice’s open balance, the system will not attach it, because doing so would close the note and lose the difference. So a credit against an invoice the customer has already paid in full cannot be applied to that invoice. It is raised against the customer, sits unapplied, and posts nothing until it is used against a later invoice. For the cut-off schedule, list unapplied credit notes separately, with the invoice they relate to taken from the reason line.

1. Filter the credit note register

   Set the issued-from date to the first day of the new year. Every note raised since year-end is now on screen, with its customer, the invoice it was applied to, its amount, status and issue date.

2. Read the year in each invoice number

   An applied note shows the invoice number it reduced. A number carrying the old year is a pre-year-end invoice. For a non-calendar year, open the invoice and read its date.

3. Split applied from unapplied

   Applied notes have posted in the new year. Unapplied ones have posted nothing and need their related invoice identified by hand.

4. Attach the reason and the approver

   Copy the reason line where there is one. The person who raised each note is stored with it, and the audit log records each one being raised, applied or cancelled, with the person and the time. Any approval beyond that lives outside the system today.

Request three: who changed the price

This is the request with the cleanest answer. Only a draft can be edited. Once an invoice is approved, the edit screen refuses with the reason; so does the save behind it, checked again rather than assumed, because an invoice can be approved in the seconds between someone opening the form and pressing save. The API refuses the same way. An invoice raised from a sales order is changed through the order, not on the invoice. To change anything on an issued invoice you cancel it, if that is still allowed, or credit it.

Before approval, the price on a manual invoice line is not typed by the person raising it. It comes from the customer’s price list, or the item’s selling price where there is none. Lines copied from an agreed quotation or order keep the price that was agreed. What the person can type is a discount per unit, and on an invoice that discount has no ceiling. The till is different: since October 2026 a till discount above the item’s own is capped by a workspace limit and needs a named approver, as A Discount With No Name on It explains. Invoices have not caught up.

So the honest answer to item seven’s third line has two parts. After issue: nobody, and here is why nobody could. Before issue: every save of the draft is in the audit log with the person and the time, and the approval is stamped on the invoice with a name and a time, as described in An Invoice That Has to Be Approved. What the log records is that the draft was saved, not which figures changed, so a discount raised on a draft and then approved is visible only as its final value.

Close the year so nothing lands in it

Everything above works better once the old year is closed. A closed month refuses any ledger entry dated into it, from any source, and an automatic posting made while the current month is closed rolls forward to the first open day rather than failing. So once December is closed, a backdated service invoice cannot book December revenue, a cancellation cannot reverse into December, and a credit note cannot reach it either. Closing is also the moment to make any adjusting journal the auditor agrees, while the period is still open to receive it. How the close works is on the month-end close page.

Frequently asked questions