I work on OnePassApps, so this is our own product and our own build. Every number below was measured on the live Invoice Maker today, in the visible Chrome on our own machine, signed out, with no account.
The Invoice Maker has two discount modes - Percent and Amount - and a field that takes a number in each. What I did not expect was what happens when the number is not one the app can use.
There is no error, no warning and no red state. The value is simply not applied.
What I typed
One invoice: one line, "Consulting", quantity 3, unit price £1,234.56 - a subtotal of £3,703.68 - and £3,703.68 tax on it. With no discount the panel reads:
- Subtotal £3,703.68
- Tax at 8% on £3,703.68 = £296.29
- Total due (GBP) £3,999.97
Then I typed 22 values into the discount field, 11 in Percent mode and 11 in Amount mode, and read the panel after each one.
12 of the 22 took effect. 10 did not. Of those 10, two are a legitimate zero - typing 0 means no discount, so there is nothing to show - and 8 are values the app cannot use.
The refusals are quiet
Every refused value left the invoice reading exactly like the undiscounted one: the same tax label, the same tax, the same total. There was no message and no marker. The only way to tell that the field had been ignored is to compare the totals yourself.
The 8 refusals fall into two rules, and the rules are not written down anywhere on the page:
-
33.333- more than two decimal places - no Discount row at all -
101- outside 0 to 100 - no Discount row at all -
150- outside 0 to 100 - no Discount row at all -
-10- outside 0 to 100 - no Discount row at all -
0.005- more than two decimal places - no Discount row at all -
3703.679- more than two decimal places - no Discount row at all -
3704- above the subtotal - no Discount row at all -
5000- above the subtotal - no Discount row at all
Two decimal places, and not one more
This is the part that surprised me, because it is a precision limit rather than a range limit.
In Percent mode, 33.3 and 33.33 both work. They give different money:
-
33.3- Discount −£1,233.33, Tax at 8% on £2,470.35 = £197.63, total £2,667.98 -
33.33- Discount −£1,234.44, Tax at 8% on £2,469.24 = £197.54, total £2,666.78
One more decimal and it stops working. 33.333 is refused exactly like a value of 101 or -10: no Discount row, tax back on the full subtotal, total £3,999.97 - the same as if I had never touched the field.
The same rule holds in Amount mode. 0.50 works (−£0.50, total £3,999.43) and so does 10 (−£10.00, total £3,989.17), but 0.005 - a half penny - is refused, and so is 3703.679.
So the field takes a number with at most two decimal places. Three decimals and the value is dropped, silently, whatever the mode.
Amount mode is also capped by the subtotal
The second rule is specific to Amount mode, and it is the subtotal itself.
3703 is accepted and takes almost all of it: Discount −£3,703.00, tax base £0.68, tax £0.05, total £0.73.
3703.68 is accepted too - the whole subtotal - and the invoice comes to £0.00.
3703.679 has three decimals, so it is refused by the precision rule above. 3704 has two, but it is more than the subtotal, and it is refused as well: no Discount row, total back at £3,999.97.
In Percent mode the same range rule appears as 101 and 150 being refused, and -10 being refused. 100 is fine - a 100% discount gives Discount −£3,703.68, tax on £0.00, tax £0.00, total £0.00 - and 50 gives −£1,851.84 and a total of £1,999.99.
Why this matters if you are billing someone
The tax follows the discount. The panel's own tax line names its base - "Tax at 8% on £2,470.35" for a 33.3% discount, "Tax at 8% on £3,703.68" with no discount - so the discount comes off first and the tax is worked out on what is left. That is the order the app takes.
The quiet part is the failure mode. If a discount is typed with too many decimals, or an amount above the subtotal, the invoice quietly becomes the undiscounted invoice. The total is not wrong in an obvious way - it is just the number you would have got if you had left the field alone, and nothing on the screen says the field was ignored. I would type the discount and then read the total back before sending it.
One build, one signed-out session, one invoice, 9 November 2026. I typed 22 values in total, one at a time, and read the panel after each. I did not test a negative amount, a currency other than GBP, a second tax rate, or the exported draft JSON, and I make no claim about any of those.
Try the Invoice Maker: https://app.onepassapps.com/apps/invoice-maker?utm_source=devto&utm_medium=post&utm_campaign=invoice-discount-refusals&utm_content=invoice-maker-link
The guide, which spells out what the app does with each field: https://app.onepassapps.com/guides/invoice-maker?utm_source=devto&utm_medium=post&utm_campaign=invoice-discount-refusals&utm_content=guides-link
Top comments (0)