A credit note is not an invoice with a minus sign. It is a different document type, and every amount inside it stays positive.
Easy to agree with, awkward to implement, because most billing code models a refund as a sign flip on an existing invoice. The receiving system then rejects the file, and nobody can tell whether the data or the format is at fault.
Here is how we settled it in invoicerules, our open-source validator.
The document type code, BT-3, with 380 for an invoice, 381 for a credit note, and the rest of the UNCL1001 list, is the single switch. It decides the root element, the line element and the quantity element. Nothing downstream re-decides it. One rule set checks both documents, so a rule you write once applies to a refund and to a sale alike.
The sign rules follow from that. A negative line amount, a negative taxable amount or a negative document total is refused, and in our codes that is INVOICERULES-CN-01. A negative item net price is refused under BR-27. Direction of money is carried by the document type, not by the sign of the numbers.
One exception is real. The payable amount, BT-115, may be negative, which is what you get when more was prepaid than was owed, and refusing it would break legitimate settlements.
A credit note also carries no DueDate element. There is nothing to be due.
The last part is not cosmetic. Failures are reported on paths inside the CreditNote tree, the same paths the receiver will quote back when they reject the file. A validator that reports Invoice paths for a credit note sends your finance team hunting for an element that does not exist.
So it comes down to how you model refunds today, as their own document type, or as negative lines corrected at export time.