To be more exact: depending on the kind of account being uses: sales or expenses. Not only the transaction (document) type, because Journal Entries can be mixed when making corrections.
Here the same mechanism applies.When you make a payment, Manager treats the VAT as "purchase-VAT regardless the fact that you book it on a sales GL-account.
I think @ Lubos has to dive into the mechanism because I think it is basically wrong.
Thanx again. It took me 6 hours during my first real year end closing to find the differences between the P&L and the reported revenue via the tax. I thought I went crazy, but you confirmed I not 
@lubos, can you please look into this?
@IntoTheMirror, thanks for the complete illustration. I will put this into bugs for @lubos to examine.
@Hennie, thanks for your analysis, too.
Iâm left with one final question: How do I post the journal entry correctly? The original amount was 17,50 excluding VAT of 21% that should have been 17,50 excluding 0% VAT.
Like this?
Nope. The details of my Tax payable on the balance sheet show me that it isnât correct. I expected a balance of 0, not 3,68.
So which journal entry should I have made?
In Australia, âManagerâ is recording the transaction as required by the ATO.
See here:
Obviously, this may not be what is required in other countries.
As previously said, journal entries, payments and receipts are tricky transaction types because they can be both sales and purchases.
For example, a payment can be a purchase but it can also be a refund (negative sale).
Currently, Manager naively considers credit amount to be a sale and debit amount to be a purchase for journal entries, receipts and payments. It could look at chart of accounts and decide based on whether account is categorized as expense or income but that wouldnât be a complete solution.
Mostly because there are still accounts which can be both.
For example, recording receipt against fixed asset - Manager cannot tell whether fixed asset is being sold or whether it is being returned and refunded.
The only way to make it work 100% would be to introduce new option on journal entries, receipts & payments where you could indicate whether transaction is considered a sale or purchase for tax purposes. Perhaps the option would be visible only if select tax code on transaction.
1 Like
I think youâre almost there.
Iâve worked with an accounting system that uses different tax codes for sales and purchasing. Maybe that can work here as well. But instead of using the double amount of tax codes Manager now has, a simpler solution can be applied.
Instead of having an indicator on the transaction, you should introduce a tax indicator: P (Purchase) or S (Sales) in the line. For purchase invoice and sales invoices (and related transaction types) those can be defaulted and hidden in the input screen.
Indeed, for other transaction types (JE, Receipts, Payments) the P and S should be visible when using a tax code on the transaction line.
The reason is using a line type indicator is that mixed documents will still give problems for some people when putting an indicator on the transaction level.
For the Tax Summary you look at the VAT code and Tax indicator to place the amount in the correct column. Do not take the sign of the amount into account.
Finally, please put the âincluding taxâ option also on the Journal Entry to complete this fix. Iâm not able to correct tax at this moment using a Journal Entry because tax is automatically included.
What do you think of this solution?
An alternative is to use
-
A localization guide informing the user which tax codes are applicable for particular transaction types. Specifying both Government specific requirements and Manager tax coding specific requirements. Journal entry requirement for specific transaction types could be specifically listed.
-
Should the list of tax code list become too long, Manger could provide a short list at the top most applicable base on context (Purchase or sale, country of customer/supplier) followed by the full tax code list. Where no short list hints are available the full list only would display by default.
The alternative is to go in the opposite direction and have qualifiers for tax codes universally supported and used. As well as a coding time commitment that also involves a display real estate commitment.
Because I was out for a couple of hours you wrote exactly what is was intending to write as a reply to what @Lubos wrote. I Fully support your solution to solve the problem. I sincerely hope @Lubos will pick this up and implements it.
Kind regards,
Hennie.
1 Like
I agree.
If you want Manager to automatically handle the tax implications of a erroneous transaction in an earlier period, the way to correct it should be:
-
Enter a negative quantity transaction otherwise identical to the initial erroneous transaction but in the new period (ie erroneous payment is refunded under identical conditions)
-
Enter a positive quantity transaction using all the correct settings.
-
The total of the above two transactions (or line items) should be the difference between the erroneous entry and the correct entry ie the required correction to all VAT entries, a process which becomes more involved now that Manger has localization calculating entries for country specific VAT/GST submissions. An updated or correction Tax invoice can also be printed where customer visible changes are involved in the error.
For those that donât want to correct errors by first undoing their mistakes or local laws require corrections to prior VAT/GST submissions are separately reported; journal entries could be used BUT doing so the user is modifying the accounting system at a low level. With low level control you get low level responsibility so the user should also be responsible for manually entering the tax and non tax component (ie only support/recommend 0% and 100% tax codes) or at least the program should make no attempt to guess if tax should be included or not. Ensuring consistency of corrections to the GST/VAT Calculation Worksheet is also going to be the responsibility of the user in this case.
Would replicating the âReceipt & Paymentâ tab
- Type (Receipt, Payment) field
in the Journal Entries tab be a consistent way of removing this ambiguity? (I assume this is a data base structure change so existing entries would have to be initialized or default to the currently assumed transaction sign based classification).
Maintaining the classification at the transaction level not line level would minimize the screen / printed document real estate penalty. It also means this change only effects Journal entries and achieves greater program consistency. A subsequent feature request could enable specification of both Receipt & Payments and Journal entries at the line rather than transaction level if that was later felt to be an improvement in the program feature / complexity balance.
Yeah, this is exactly what I was trying to avoid from the very beginning.
I get this but I think itâs no different from just having double amount of tax codes.
Have a look at this feature request:
Basically, once we allow to select customer or supplier on payment/receipt forms, we will be able to tell whether a receipt is a sale or refunded purchase. Just by looking at the type of contact the receipt is linked to. Is it linked to a supplier? Itâs a refund!
There is no reason why journal entries couldnât be linked to a customer or supplier too.
I find this much cleaner approach because people want to select customer or supplier on receipts/payments/journal entries anyway if applicable so these transactions can show in customer/supplier history.
Perhaps Manager can evolve so for every tax transaction customer or supplier should be known. When you are in tax summary report and click on Tax collected or Tax paid figure, you could get tax totals by customer/supplier rather than list of individual transactions.
Hmmm, interesting point of view. Itâs the P or S on the transaction level.
But you still have the problem of mixed transactions:
- a purchase invoice ( P) containing returned goods ( P) or sold goods (S)
- a sales invoice (S) containing commission that has to be paid ( P)
Those are the hardest differences to find if things donât balance at year end closing for instance. And for the sales invoice one can say that you shouldnât do that in Manager. But you donât have much to say over purchase invoices you receive.
I still believe in a line level solution, not a transactional level. But Iâve have no suggestions how to implement it in your preferred cleaner approach. So what you suggest by adding customer/supplier to receipts/payments/journal entries I think itâs fitting Manager the best.
Personally Iâm more interested in the tax on the expenses and revenue lines, not the supplier/customer. Our tax administration is more interested in the revenue basis than the revenue per customer for instance. And that revenue basis is being used for VAT as for income tax. So they should be equal. But maybe for other countries it could be interesting.
What do you think of this adjustment on the JE?
But tax on sales invoices will be always be considered tax on sales and tax on purchase invoices will be always considered tax on purchases.
In theory, you are right. The entire transaction is either sale or purchase but letâs be realistic here. What is the use-case for transaction to be a both sale and purchase at the same time. It doesnât seem to me there is a scenario where that would be the case.
Itâs still useful. You can double-check you are not collecting tax from customers who are not to be charged tax or not claiming tax on purchases where you are not meant to claim it.
I think the break-down of tax amounts by accounts AND by customers/suppliers are both useful regardless of the country.
This wouldnât make sense. Journal entry is the only transaction where debits and credits must balance. If there would be an option to enter tax-exclusive debits/credits on journal entry, then tax is added on top of debit or credit amounts resulting in unbalanced journal entry.
Would not returned goods be put processed as a negative quantity at the item level yet the transaction type is unchanged to ensure reversal of the applicable tax implications and supplier / customer relation/database entry. Similarly there should be not change from an Accounts receivable to Accounts payable but rather a negative value entry.
Thus a good return with purchase of a replacement would be all the same at the transaction level, differing only in the sign at the item level.
I would like to put forward this scenario to be considered in the context of this thread:
The highlighted amounts are for a journal adjusting GST for previous period. The other amounts are for current period.
The amounts under the sales headings would become negative amounts if they were under the purchases columns. So, the GST 10% under the purchases columns would become: $-40.00, $-4.00, and $-44.00.
This would result in negative amounts on the BAS Return which are not permitted.
(i.e. G17 and G19 would be $-44.00 and G20 $-4.00)
Iâm with @Patch on this: an exchange. In fact, that is exactly how exchanges are suggested in the Guide: https://www.manager.io/guides/12626. The use case does not even require an invoice. It can be handled as a cash transaction, although the same philosophy applies with invoices.
OK, so how do I solve this one? (By the way, I love the new language selector!)
The 3,68 is reduced on the VAT balance account by the first line which is the purpose of this transaction. The net expenses are 0 (17,50 credit and 17,50 debit). So where do I post the 3,68 credit amount to?
Whatâs the point of this journal entry? You paid 21,18 EUR for something where you claimed BTW 21% but you shouldnât have? Then both amounts on journal entry should be 21,18 EUR.
Indeed.
But if the second line is 21,18 as well, my net total expenses in the P&L increases with 3,68. I was only invoiced for 17,50 EUR excluding VATâŚ
In this case my Tax balance sheet account is balanced. And that is not the case. The tax has to be reduced by 3,68. So this is not a solution as well. Other options?