Why do the costs on a journal entry show in the net sales column?

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:

  1. 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)

  2. Enter a positive quantity transaction using all the correct settings.

  3. 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…

20

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?

If you’ve been invoiced 17,50 and there was no VAT and paid 21,18 EUR, then you overpaid supplier 3,68 EUR. Where is this 3,68 EUR now? Are you going to get refund? I mean it is just 3,68 EUR but double-entry accounting won’t let you “forget” anything. You are trying to make a journal entry to somehow make 3,68 EUR disappear. That’s not possible.

Oh ****. I’ve looked again to the whole of transactions that created this situation. I’ve should have noticed a payment difference on the original invoice. And indeed I made one. So to balance the JE I have to reverse the payment difference entry I made on the payment. So the JE has to be:

I feel a bit stupid :flushed:. You don’t need a checkbox without VAT on the JE. Problem solved regarding the JE. Thank you time and for your replies!

But then there is still the problem that all credit and negative debit postings on a VAT-code are recorded as a sales transaction and the other way around all debit and negative credit postings on a VAT-code are recorded as a purchase transaction.

Under current implementation… yes. But once journal entries, receipts and payments can be linked to customers or suppliers, then Manager will be able to correctly tell whether transaction relates to a sale or a purchase (regardless of debit/credit).

Any idea when this will be realized/implemented ??

@lubos
At the end of fiscal 2018 I had to make an accrual for work in progress.
The accrual (journal-entry) I made was:
Work in Progress (balance-account) Debit € 2311.52
At work in Progress (P&L-account Credit € 2311.52
The applicable VAT-code was BTW 0% vrijgesteld

At the start of 2019 I reverse this journal entry and I made the following journal entry:
Work in Progress (balance-account) Credit € 2311.52
At work in Progress (P&L-account Debit € 2311.52
When I look at the Tax-Summary it shows

The VAT Calculation worksheet shows:

It is obvious that the VAT Calculation worksheet and the Tax-summary report, report wrong values.
The values reported should be 78462.08 minus 2311.52 equals 76150.56 instead of 78462.08

I sincerely hope that you will modify in due course the way the VAT is calculated because Manager now reports wrong values which lead to wrong Vat-tax-returns.