I am not convinced that there are any laws that state that you have to display the invoice in a certain way - all that is required is that somewhere the customer can see what tax they are paying. But as the developer lives in Australia he will know better than anyone else what the requirements are.
For me personally, this issue does not affect me as I don’t use cash transactions or tax inclusive. I just found the topic interesting and put my recommendations down which is keep the forms as identical as possible, but only if consistency makes things easier to do, not harder. Consistency is meant to make things easier, but sometimes that does not work.
It is not redundant in my country (Macedonia and most neighbors). It is required (even I agree it is redundant info) by both tax legislation and common business practices. Here are the required fields, and not required but long one established ones on invoices, with my current theme (header row - white one not required by Law, black required by low)
Possibility 2 would not work for restaurants and many retail outlets. VAT inclusive pricing with the amount of VAT as per your 3rd illustration of current situation (9.09) is the dominant mode. Indeed it would be useful if itemized, but in our jurisdiction not required. I am not sure if I understand possibility 2 that well, but it would not work for us if not showing tax-inclusive pricing.
I’ve been working on this concept for the past few days. Obviously, before standard layout is rolled out to every transaction form, we need to figure out what that standard layout should be. There are a few topics in ideas category asking for various things so I’ve looked at all that and came up with following.
Transaction without discounts, tax codes and quantities
So the idea here is that complexity and number of columns grows as needed. Now add custom fields, items, multi-component tax codes and some transactions can have so many columns that the transaction will need to be printed in landscape format (rather than portrait) which is fine.
This new layout is currently enabled on Purchase Quotes only. Also, at this moment only in cloud edition. It will be available in desktop edition soon. Until then, you can sign up for free trial to test how this all works on purchase quotes before it’s progressively rolled out onto every other transaction type.
Reason why I’m doing this is that there are about 5 topics in ideas category that will solved by this new layout. And more topics in ideas that will be easier to implement once this layout is rolled out.
One question and some comments. First the question:
What happens when line items have different tax codes applied? Is the column you have labeled GST 10% renamed as something else, like Tax Amount? Surely you are not just adding more and more columns for different tax rates, are you?
Now the comments:
The tax-inclusive layout is quite confusing. Nothing actually indicates amounts are tax-inclusive. We are also powerfully conditioned to expect the final amount on transactions to be at the bottom corner. Yet in this layout, that space is given over to the tax total and transaction total is hiding out in the middle of a series of totals.
It would also help to see the mini-statement layout. Where does the current totals section lay out in this concept?
That’s tax component name. If there are multiple tax components names, they will show as separate columns. You can name all your tax components Tax amount if you want them to merge into single column with Tax amount label.
I made it bold to give it emphasis.
That I’m not sure yet. Probably mini-statement should be a separate mini-table rather than connected to this one.
Currently the output format depends on how the data is entered.
Imo it would make more sense if the output format was a business preference. Data could then be entered in what ever format was most efficient.
But can live with the current method if a significant number of users need to support multiple formats from the same business.
During data entry I much prefer to see all of the columns (tax exempt, tax, tax inclusive) as some invoices supply a random combination of information which are otherwise hard to decipher.
First of all good initiative to try to tackle so many issues and ideas. The form you show includes the necessity by tax authorities for unique consecutive serial numbers. This is indeed somewhere in ideas as well but it will necessitate another column in the table and thus taking more unavoidable real estate when all applies.
It is important to as in the current invoices indicate tax inclusive or exclusive and also to clearly post this as part of the totals on the bottom right. Bolding a single total is actually confusing and a more standard presentation with subtotal → tax (Vat incl or excl) → shipping & handling (if applicable) → Total , would
I don’t mind the added columns, but I don’t like two things about the totals layout:
The order of columns isn’t fixed, example 0 rated taxes go behind the amount. I prefer that the columns sort order remains fixed with the totals amount being last. Also, all summable amounts should come last.
The previous totals sections is much more elegant and more commonly used. I know that they wouldn’t add up to the the last column. However, this problem can be solved by matching the totals label to the column heading. I believe this would be tidier and more palatable.
What I’m thinking of is something along these lines:
All the information required are displayed without breaking the conventions when it comes to totals display. I personally think that these totals are more readable and understandable this way as opposed as laying them out in a single row.
@Ealfardan we should still have totals under each column where applicable. Mostly because this will allow us to show totals even for columns that do not contribute to transaction total in any way. For example Qty column or various custom fields (both feature requests in ideas category).
This brings me why repeat all that again in vertical total section. But we could. Especially when transaction has columns with various totals but only some of them are part of the transaction total calculation.
Whether @Ealfardan’s recommendation on the vertical totals section is followed or not, his post contained two important points, in my opinion:
The order of columns remains fixed, regardless of whether the transaction is tax-inclusive or tax-exclusive. Changing column orders may not bother a transaction recipient, since they typically see only one transaction at a time. But it is very confusing for accounting personnel in businesses that use both inclusive and exclusive transactions. And it is unnecessary. Why go to all the work of standardizing layout only to flip back and forth when a checkbox is ticked? Constancy of column order was a principal feature of my recommendations in post #1 (when I started this topic) and post #13. Headings changed as necessary to reflect inclusion or exclusion of tax.
The ultimate total, balance due, or whatever is being displayed by the particularly transaction form is in the almost universally accepted lower right corner (for left to right languages) rather than buried in a middle column. Yes, I know you tried to emphasize it with boldface type, but that was not very effective. In fact, rather than leading me to an awareness that that was the important number, it left me wondering why it was in bold type. Realization that this was what I should focus on only came later, after the confusing tax-inclusive layout was puzzled over for quite a while.
But that’s forcing the table to do too much at a time which detracts from the main purpose of the document. But as with other things in life, this boils down to being a trade-off, so we should weigh the costs against benefits and compare all possible alternatives.
And that begs the question: Since payments were left out from all of the examples above, what would happen to the payments? How would they be displayed?
Currently there is no other way to know how and when a particular invoice is paid except by going to the invoice and getting the payment reference from there. To me at least, that’s a more valuable feature than being able to show custom totals and I suspect that most users would agree. For one, you could easily write a theme to sum up the quantities or a custom field, but it’s impossible to write a theme that show the payments towards an invoice.
Why not have these additional totals displayed as a note after the amount in words and before custom fields? For me that would seem like the best place for any extra non-financial information. This frees the main table to give the financial data their due attention. For example:
On another note – while I can’t object to keeping up with regulatory requirements no matter how overboard they may seem, I agree with @Tut, it’s true that landscape page could fit more columns, but at some point the format is going to get too overcrowded to be legible.
I can’t help but to wonder, is this something that users will be able to undo? Possibly a checkbox in the Tax Code form to display components as separate columns?
I say this since not all users have a legal obligation to display all this information and they would much rather keep their invoices simple to save paper and to display a more presentable format to their customers.
I think a lot of people are getting lost in the detail. What I would suggest is stepping back and asking - what problem are you trying to solve by changing the format of the layout? I just feel that things are being over complicated here and what problem is actually being solved has been lost in the process.
In the initial posts - yes. But the solutions seem to be over complicating the issue and creating more problems than it is solving from what I am seeing. It looks information overload on the forms.
