Capital sub account tax code

I think there is a bug when using tax codes and capital sub accounts.
Using v19.7.24 desktop on Windows 7.

  1. An example I would like to use
    Journal entry from “Retained earnings”
    to “Capital Accounts” -> “Member 1” -> “Share of profit” - tax code
    Changing the tax code makes no difference. 100% funds are transferred to “Share of profit”, none going to any tax code directed account.

  2. An example showing an issue but I don’t think I need to use currently
    “Receipts & Payments” -> “New Receipt”


    Appears to work

    But no funds get to “Tax payable”

    Instead all going to the capital sub account

PS
My use case (but probably not directly relevant to the bug)
I would like to have an “Income tax” code with a liability account say “Tax Income payable”. Then a journal entry from retained earnings to share of profit could calculate and deduct the associated income tax. Clearly I could manually calculate it and allocate to the same account however a tax code calculated would be less error prone and may facilitate later custom reporting.

If I understand it right, I think that you are using tax codes for profit taxation at the end of the year. If so, you are using them improperly since they are created for value added taxes.

Manager has a bug.
If you look at the image of the edit screen, View screen, and actual account movement then The code is not doing what it says it is.

You are correct there is more than one solution. My preferred is for Manger to do what the entry say it will do. The alternative is to prevent entry of tax codes on Capital sub accounts.

I was hesitant to describe why I tested the program in this manner as I assumed I would be told others have not used Manager that way.
As for why I’m using Manager in a non-standard way. Profit distribution after tax however is not probably not that uncommon. I assume others manually calculate the tax and allocate it to an income tax liability account when distributing profit. In Australia, Superannuation fund income tax is 15%, General company tax 30% (small business a little lower), both of which are a constant rate, so a Manager tax code will calculate the correct amount of tax. Manager also has the ability to put the tax in a tax code specified account, so it can readily be separated from the GST/VAT account. Australian Superannuation tax law requires Member concessional (pre tax dollars ie a tax deduction on the members tax return) are considered taxable income when received by the Superannuation fund. So 15% tax needs to be calculated and subtracted prior to adding to other member contributions (non-concessional or rolled over from another superannuation fund). As a result the 15% tax calculation needs to be done multiple times. Sure I can do it manually but the opportunity for calculation errors is lower if automated, particularly given Manager already has the facility, even if others haven’t used it that way in in the past.

I don’t call it a bug. As far as I understand, since you didn’t post all the screenshot, you are trying to use value added tax module to write the superannuation taxes. But your account writings are not value added since they are balance sheet Vs balance sheet and you can only add value to a company by changing the P&L.

One last consideration, very personal. Your are saying that you are doing this to prevent errors… but since this writing is done once a year through a simple moltiplication, does it really make sense to improperly use Manager’s tax module to do this?

Tax codes work on all other balance sheet accounts. Both for “Journal entries” and “Receipts & Payments”
It is only Capital sub accounts in which the specified tax code makes no difference to the actual fund movement (despite clearly showing a different transaction on the view Receipt screen).

Sorry to confuse things by given a use case.

Can you post the screenshots?

i maybe wrong and i accept i am not good with accounting, but why would you want to mix up things with sales/service tax and income tax?
the Tax Payable account is designed to handle sales/services tax not income tax.
i believe the transactions related to capital accounts are not sales/service.
if you add a tax code for such transactions, the Tax payable value would not reflect the actual credit/debit available with the tax authority.

and i think Manager is working exactly as per accounting principles to not show the tax on capital contributions under Tax payable.

I agree with you… you can separate it with control accounts under balance sheet but it will mix the results under reporting. Very risky since we are talking about taxes and tax authorities.

Receipts transaction for Balance sheet accounts. All for $1000 all with GST 10% (Australian localization tax code as an example).
bug%205%20test%20accoiunts

  • View screen of all Receipts show $90.91 GST is included 7 of 7 Balance sheet accounts tested

  • Actual transaction includes GST transfer to account specified in tax code in 5 of 7 Balance sheet accounts tested

I need to see the input screen of the journal entry that you made. Not the result

The edit screen and Receipt view screen are all exactly the same as the opening post (differing only it the Balance sheet account for each example & $1,000 not $100,000) for the 7 Balance sheet accounts shown above. Results as shown in above post.

If you doubt my ability to do this 7 times try it your self, takes about 1 minute.
A lot longer to capture all the screen shots, trim and upload.

what about the date?
in your initial post the date of receipt was 05/07/2018
in the recent post the summary is set only to show transactions for 28/07/2019

Fine. I was just trying to help you since I don’t have access to my computer today. Hope you’ll find a solution by yourself. Good luck!

It’s a program bug so I can’t fix it. Lubos may well consider it a low priority bug as few people notice it.

I can readily work around it by manual calculation. I was considering making a localization report transformation to summarize Australian SMSF reporting & calculations which is more achievable with the uniformity introduced by taxation codes but again doing it all by hand isn’t too hard with few members and infrequent changes in members equity ratio. (The calculations need to be repeated whenever there is a change in equity ratio or any member makes a concessional contribution).

Confusion with other taxation codes isn’t relevant as the Australian localization report transformations only look at those specific GST taxation codes and produce easily interpreted reports.

It has to and does work for Fixed assets as there is GST on those purchases. Similar functionality for Capital accounts I assume would require similar coding.

After reading this entire thread, I think the issues have been exposed. But if there is anything that could be considered a bug, I think it lies in allowing (and showing) a tax code application when posting to a capital account. I believe the solution is not to allow tax codes for capital account postings, because as @Davide pointed out, there is no valid use case within the framework of Manager’s tax module.

It seems the program behaves correctly when it fails to allocate tax on a capital account transaction. But it behaves incorrectly by showing that it did.

I would be very interested to learn of @tony’s opinion on this. @lubos, is there other reasoning about the program I am failing to see? Until reading more, I am not yet willing to categorize this as a bug, but I am leaning in that direction (although for a different reason from @Patch’s concern).

As far as I understand @lubos developed capital subaccounts with a future idea to develop the Capital Accounts module but it was left in an early stage.

In the last few days we had at last a couple of issues linked to this module.

For sure the use of @Patch is inapposite (and I would not use the software in this way mixing VAT with revenues’ taxation) but the way Manager behaves in Capital Accounts module is incoerent with the rest of the software.

It seems that the Capital Subaccounts are a sort of nobody’s land both for data input and for reporting.

I totally agree with this analysis by @Tut.

I think that @sharpdrivetek has already alluded to the fact that the tax field in transactions calculates a Value Added Tax (VAT). The tax on superannuation contributions/earnings is not a VAT but a Value Deducted Tax. So using the VAT fields for superannuation will never calculate the correct amount.

Using special accounts with a Control Account in the equity section, and then creating invoices for receipts using the Withholding Tax feature may be a solution for you @Patch.

@tut I think it is more workable to control the output with tax reports ignoring GST on personal capital account transactions than it is to place functional restrictions on the few capital accounts that creates additional complexity to the whole chart of accounts.

Ooops! I have just re-tested this and I don’t think it would provide what you need.

Sorry, @tony, but you lost me on your response. Are you expressing the opinion that there should be no restrictions on applying tax codes to capital account transactions? Because functionally, there already seem to be; they just don’t show properly when viewing transactions. (The completed form says tax was applied, but there is actually no effect.)

Or are you saying you think it is fine as is, with the tax reports simply ignoring the application of tax codes because it makes things too complex otherwise? (And it isn’t just the reports that ignore the tax code; no tax is posted to Tax payable, either.) Can you clarify, please?