Invoice Generator

An invoice looks like paperwork, but it is really a small piece of arithmetic that two parties agree to trust. The seller says what was supplied, at what price, with what tax, and what is still owed. The buyer checks it, pays it and files it. If a single cent fails to add up, the trust goes with it.

That is why an invoice tool should be judged first on its sums, and only then on its looks.

What an invoice has to make clear

The United Kingdom’s government guidance gives a plain list. An invoice must carry a unique identification number, your name, address and contact details, the name and address of the customer, a clear description of what you are charging for, the date the goods or service were supplied, the date of the invoice, the amounts charged, any VAT, and the total owed. The same page draws a line worth remembering: an invoice is not a receipt. A receipt acknowledges a payment, while an invoice asks for one.

Tax law adds detail on top. The VAT guide from HM Revenue and Customs asks for a sequential number based on one or more series, the rate of VAT and the amount excluding VAT for each description, the unit price, and the total VAT. The European Union’s VAT directive asks, among other things, for the taxable amount per rate and the VAT rate applied. It also lets the amounts appear in any currency, provided the VAT payable is expressed in the national currency of the country where the supply takes place.

Those rules are not universal, and they change. A tool that makes invoices cannot know which ones apply to you, so the honest design is to leave room for them: fields for tax numbers, a free text block for any statement your rules require, and labels you can rewrite in another language. It should also say plainly that it is not producing an electronic invoice. Several governments now require structured electronic formats for business invoices and store them centrally; Mexico, for example, introduced its CFDI format in 2004 and has banned non-standard invoices since 2012. A printable PDF does not meet a mandate of that kind, however tidy it looks.

Payment terms belong on the face of the invoice too. Wikipedia’s article on invoices notes that terms usually state how many days the buyer has and sometimes offer a discount for early payment. “Net 30” means the full amount is due within 30 days, and “2% 10, net 30” offers 2 percent off if the buyer pays within 10 days. In the UK the government’s guidance adds a default: unless a payment date was agreed, the customer must pay within 30 days of getting the invoice or the goods or service. A seller who writes the due date out as a calendar date, rather than leaving the buyer to count, removes one excuse for paying late.

Why money must not be floating point

Most programming languages offer one obvious type for numbers with a fractional part, and it is the wrong one for money. JavaScript’s Number, as MDN describes it, is a double-precision binary floating-point value. Integers are exact only between minus and plus 2 to the power 53, less one, because the significand holds 53 bits. Fractions fare worse. Wikipedia’s article on floating-point arithmetic explains why: in base 2, only fractions whose denominators are powers of 2 terminate. A tenth does not, so 0.1 is stored as the nearest binary fraction, slightly off.

The result is famous. Ask a browser for 0.1 + 0.2 and it answers 0.30000000000000004. On its own that looks harmless, since it rounds back to 0.30. The damage appears at the rounding step. A unit price of 1.005 times 100 gives 100.49999999999999 in the same arithmetic, so a program that converts to cents and rounds half up will charge 1.00 where the exact amount, 100.5 cents, should round to 1.01. Errors of that size are rare, but on thousands of lines they turn up, and an invoice that is wrong by one cent is still wrong.

The cure is not more decimal places. It is to stop using fractions at all. Hold every amount as a whole number of the currency’s smallest unit, parse what the visitor typed as text without ever converting it to a binary fraction, and do every multiplication and division on integers. JavaScript’s BigInt type, per MDN, represents integers of any size and refuses to mix with Number, which is exactly the discipline money needs. A division that must land on a whole cent is then a quotient and a remainder, and the remainder decides the rounding with no guesswork.

The smallest unit is not always a hundredth. ISO 4217, the standard list of currency codes, gives each currency a minor unit: 0 for the Japanese yen, 2 for the euro and the US dollar, 3 decimals for the Bahraini dinar. Two currencies, the Mauritanian ouguiya and the Malagasy ariary, divide by five, and ISO still lists them as 2.

Browsers carry their own idea of this through Intl.NumberFormat, whose resolvedOptions method reports how many fraction digits it would show. They do not always agree with ISO. In the JavaScript engine this tool was tested with, sixteen codes differed, including the Hungarian forint and the Indonesian rupiah, shown with no decimals where ISO lists two. An invoice tool should state which source it follows and let the visitor override it.

Tax rounding is a choice, and places choose differently

Even with exact arithmetic, tax rarely comes out in whole cents. Twenty percent of 3.99 is 0.798. Somewhere the fraction has to go, and there are two questions to answer: where to round, and which way.

Where to round is the larger question. You can round the tax on each line and add the results, or add the exact tax per rate and round once. Wikipedia’s article on rounding points out that the sum of rounded numbers need not equal the rounded sum, and that is all the difference between the two methods.

HMRC’s VAT guide allows both, with conditions. It lets an invoice trader round the total VAT down to a whole penny, and for VAT worked out line by line it allows rounding down to the nearest tenth of a penny or rounding to the nearest penny or half penny, with one firm instruction: whatever you decide, you must be consistent. Retailers who calculate VAT at line or invoice level get a different rule: they must not round the VAT figure down, though they may round each calculation up or down.

Which way to round matters too. Rounding half away from zero is the rule most people learned at school. Rounding half to even, also called bankers’ rounding, is the default for binary floating-point results in IEEE 754 and, per Wikipedia, minimises the expected error when many rounded figures are summed. Truncation looks innocent and is not: the Vancouver Stock Exchange started an index at 1000.000 in 1982, recalculated it thousands of times a day with truncation, and watched it fall to about 520 in 22 months while the market rose.

Here is a worked example you can reproduce on this page, because it is the sample invoice it opens with. There are five lines in euros: 7.5 hours at 40, two parts at 1.33, twelve parts at 0.10, two booklets at 4.99 less 0.50, and 0.75 of a monthly licence at 12.345 less 10 percent. The last line is 9.25875 exactly and becomes 9.26; its discount is 0.926 and becomes 0.93. A 5 percent invoice discount of 16.08 is shared over the lines in proportion to their size.

Three lines carry 20 percent tax. Rounded line by line, half away from zero, the tax at 20 percent is 57.74 and the invoice’s tax is 58.19 against 58.18 when the same lines are rounded once per rate total. Switch the rounding point and the cent moves. Neither figure is wrong; they are answers to different rules, which is why the rule belongs on the invoice.

The direction of tax also matters. Prices can be written excluding tax, with the tax added on top, or including it, where the tax is the part of the gross price equal to the rate divided by one hundred plus the rate. Both are common. An invoice that does not say which one it uses invites a dispute about the total.

Keeping the record yourself

An invoice outlives the transaction. The Internal Revenue Service lists invoices among the supporting documents a business should keep, and says to keep them in an orderly fashion and in a safe place. How long depends on what they support: the general period is 3 years, rising to 6 years if income was under-reported by more than 25 percent and to 7 years for a bad debt deduction. Electronic records count, but they must stay readable for as long as they matter.

That argues for owning your copies in formats you can open without the tool that made them. A PDF with real text can be searched and read by any viewer. A CSV of the lines can be loaded into a spreadsheet, with one caution from OWASP: a cell that begins with an equals sign, a plus, a minus or an at sign may be run as a formula, so a careful export quotes every text field and puts a single quote before such a cell. A JSON copy of the invoice can be reopened and edited later, as long as the reader that opens it is strict and refuses anything it does not fully understand.

Dates deserve the same care. Due dates should be counted on calendar days with no time zone attached, so that a payment term of 30 days lands on the same date for both parties, including across month ends and leap years. Intl.DateTimeFormat can tell a page which order of day, month and year its visitor’s language prefers. The date itself should not change because of where it is viewed.

What a tool like this cannot do is just as important to say. It cannot tell you which rounding rule your tax authority expects, whether you must register for a tax at all, or what extra statements your country requires on an invoice. It cannot turn a PDF into a structured electronic invoice. It can only do the arithmetic exactly, state the rules it applied on the invoice itself, and hand you files you can keep.