Sales amount difference

[Ealfardan]

@lubos

However, what I’m thinking is that this account should not be available for manual entries.

This shouldn’t be a quick decision, there’s a lot of things to consider such as:

• How do we record tax payments/receipts then?

• Also, I have made lots of adjustments to tax payable using Journals before the introduction of passthrough code, what will happen to those?

• This means that setting up the starting balance for taxes payable will be too complicated to setup using invoices or Journals, which is a bummer.

Is it possible to pass on this restriction because it will probably ruin the tax books of a lot of users, that would be 7+ years worth of transactions for many users.

[Patch]

@lubos

I think creating default Tax payable account is correct.

@lubos

However, what I’m thinking is that this account should not be available for manual entries.

So does this mean

• tax codes default to this account
• The account appears on the chart of accounts only if it contains any transaction
• But manual selection of the default account is not possible (in tax codes and maybe elsewhere), if users need that they create a conventional account

[Tut]

@lubos

I think creating default Tax payable account is correct. Otherwise it goes to Suspense and then people are confused why so many amounts are in suspense

I do not find this reasoning to be persuasive. When the original, built-in Tax payable account was deprecated, you told us that defining tax liability accounts as ordinary accounts was superior for a number of reasons, including the possibility of multiple accounts for different tax authorities or tax codes. I think it has worked well, with much greater flexibility and individual control. Now we are confronted with this residual, built-in account. In my opinion, it is the presence of the built-in account that has caused confusion. Problems with the absence of a built-in tax liability account were easily recognized and resolved.

@lubos

I’m thinking is that this account should not be available for manual entries.

Then why have it? If collected tax amounts end up being posted there, you must have the ability to post payments there, too.

@lubos

The moment you need to clear this account, you should create custom balance sheet account and edit your tax codes so they redirect to your custom balance sheet account.

I strongly disagree. You should be able to set the chart of accounts and tax codes up properly from the beginning, not be faced with the prospect of having to change them when it is time to remit to the tax authority. Think about this. What you are saying is that when it is time to pay your tax bill to the authority, you must think, “Oh, I’ve been using the wrong account all along and all my tax codes are improperly defined. My tax is due tomorrow, but before I can pay it, I have to spend time revising my tax codes and balance sheet. And, by the way, the financial statements I’ve been giving to my banker and my management team are all wrong.” That is disastrous!

@lubos

What we are doing here is to make Manager useful as soon as possible with as little as possible up-front configuration.

That is a nice goal, but not at the expense of having to revise work later.

@lubos

Basically defaults are good until you outgrow them one way or another.

But outgrowing the default should never require undoing everything you’ve done before. Evolution should be a smooth addition of capability, not total disruption.

@lubos

So let’s think of Tax payable as semi-Suspense account.

No, please, let’s not.

@lubos

The same principle could be used in other modules.

I certainly hope not. Users will be hopelessly lost.

The idea that you first create a suitably named tax liability account, then create tax codes to feed it is very straightforward. Mixing built-in accounts that you cannot use with the need to interrupt your work to set things up correctly later just sounds terrible.

[Patch]

There was some confusion at the transition, when upgrading software make old entries wrong (tax in suspense).

• The problem there is not that you need to set up a tax account when defining tax codes, but than you didn’t in the past.

• A solution to which is when UPGRADING from a version of Manager which used the old default tax account to a versions which doesn’t AND tax codes have been defined, then the upgrade script should create the old default account as a normal account and link tax codes to that.

For many users in the future Country specific localisations are likely to define tax codes and tax accounts making this mute.

[Tut]

@Patch

the upgrade script should create the old default account as a normal account and link tax codes to that.

That is exactly what happened when the transition first happened.

[sharpdrivetek]

in my humble opinion Manager should have consistency across the program.

either Manager should automatically create all default accounts which could be edited and re-allocated as per the user choice,
Or guide the user to create necessary accounts before creating transactions.

what leads to confusion is the fact that for most features Manager creates necessary accounts automatically. for some it does not. and now we are dealing with partial account creation too in this case.

my suggestion would be that Manager creates accounts automatically across the program. that would make Manager useful without much up-front configuration.

[ATMCAssociates]

My suggestion is:

1. Make the system generated Tax Payable to accept manual entries for bank payments/ receipts and adjustments entries. Adjustment entries may be given some warning before posting.
   As a further suggestion: separate menu items like Tax Payment, Tax Refunds, Tax Adjustments would be included to restrict unnecessary entries in to Tax Payable account as created by system.

2. Leave the current flexibility to create user created liability account to track tax which can be assigned when a tax code is created. This is helpful when country specific circumstances is considered.
   Maybe technical notes require some explanations to these alternatives. System currently is very much user friendly and above suggestions will make it consistent and more user-friendly.
   Thank you.

[Ealfardan]

@ATMCAssociates

separate menu items like Tax Payment, Tax Refunds, Tax Adjustments would be included to restrict unnecessary entries in to Tax Payable account as created by system.

Allow me to disagree in a very passionate manner.

There’s absolutely no difference between tax payments and regular payments on one hand and no difference between tax refunds and receipts on the other hand other than the line account. Which you can change in a normal receipt/payment.

This excessive pigeon-holing can only be found in QuickBooks, which is a dying platform. Let’s not forget that the popularity of Manager comes partly as a result of the large list of QuickBooks failures, one of them is overcomplicating transactions in this manner.

To me at least, copying the faults of QuickBooks is a stupid move especially since the developer already knows that all of the users prefer Manager over QuickBooks.

Just google QuickBooks and you will see how every other accounting package advertise themselves as QuickBooks alternative and that should tell you something about how QuickBooks is doing.

What’s next after Tax payment, Tax adjustment, Tax refunds tab? Sales receipt tab, cheques tab, cheque payment tab, deposits tab, expense tab, pay bills tab?
That sounds excessive to me and my response would be resounding no.

For those who prefer this type of setup, QuickBooks provides exactly that so it seems like a waste of effort trying to make Manager like QuickBooks when you already can have QuickBooks.

No one ever wondered before this point on how to pay or refund tax balances because it’s intuitive:

• Gave someone money? Use the Payments tab
• Someone gave you money? Use the Receipts tab

Overcomplicating things with arbitrary distinctions on what why tax payments are different from payment will only leave us in a position where users not knowing what goes with what, exactly like QuickBooks. Even worse, there are many situations in QuickBooks where the transaction don’t fit any of the pigeon holes. What to do then?

Sorry for the lengthy rant but going in this direction will bring Manager from one of my top 3 software down to the bottom right next to QuickBooks.

That would be a deal breaker for me.

[ATMCAssociates]

Thank you so much for the comment. Differences of opinion would all be good for us to have. Sometimes, one would say journal entries would suffice and be easy as an accountant because all what matters is debit and credit. Still I respect that person’s views.

Manager is having very user friendly arrangements specially regarding Fixed Assets and Payroll. As I have worked in many different accounting software, I just communicated my suggestions if it would be helpful. Kind regards.

[lubos]

@sharpdrivetek

either Manager should automatically create all default accounts which could be edited and re-allocated as per the user choice,
Or guide the user to create necessary accounts before creating transactions.

It’s not as simple. Tax payable account is kind of a weird case.

Basically, let’s call all these built-in accounts as conditional accounts.

They only appear if certain conditions are met. I do not want conditional accounts to have ability to have starting balances.

This is because if you set starting balance on conditional account and sometime in future conditions for that account to exist are no longer met, it must disappear from your chart of accounts automatically. But if it disappears while having starting balance, then your starting balances will no longer be correct.

Not having starting balances on conditional accounts is working fine because most of these accounts in Manager are control accounts. Control accounts such as Accounts receivable, Inventory on hand etc do not have starting balances. If you decide one day, you do not want built-in Accounts receivable. You are going to create custom control accounts and re-assign all your customers to your custom control accounts, built-in Accounts receivable will disappear without having material effect on anything. It’s safe to do without consequences.

However, Tax payable is not a control account. The conditions for Tax payable built-in account to exist is that you have at least 1 tax code which has non-zero tax rate and is not linked to any custom general ledger account. Then Manager will post tax amounts to Tax payable account. Thus Tax payable will exist.

I know what you say now… why not extend the conditions so Tax payable will only disappear if

• No tax code using it
• And no direct entries debiting or crediting the account
• And no starting balance set

And I could… but this would have performance implications. Now the conditions for this account to exist relies on scanning the entire general ledger to see whether anything is manually posted into this account.

So this is why some time ago, I got rid of Tax payable account altogether and simply all tax amounts were posted to Suspense account by default and user was expected to create and select custom general ledger account when creating tax codes.

Eventually I realized Suspense is too much. Because if user has bunch of tax amounts in Suspense account, it’s not so obvious why there are there or even what they are. And Manager knows why they are there and what they are. It’s just not obvious to user. So to make it obvious to user, instead of dumping all these tax amounts to Suspense account, I’m just dumping them into built-in Tax payable.

So to recap…

• There is a performance reason why I don’t want conditional accounts such as Tax payable to have starting balances or ability to directly post to them.
• But I do not want to get rid of Tax payable account completely. It’s still useful as a temporary placeholder account so tax amounts end up there rather than in general purpose Suspense account.

[AJD]

The problem with this approach is that this configuration only serves to create more work for the user.

To set up tax codes the user should be prompted, at the very start of the process, to create a Tax Payable account in the COA. Then on import of country specific tax codes(or tax code creation) the user would select this account. This will avoid having to expend time working through issues encountered in the current configuration when needing to set a starting balance or process a tax payment or receipt, and finding it necessary to change the payable account in every tax code.

[Ealfardan]

I don’t see any trouble in getting the user to create their own tax accounts.

In fact, if I understood correctly, Lubos hinted that users should create their own tax accounts but just in case they didn’t – and many of us don’t, including me – the tax transactions will not be thrown into suspense. And that’s the whole point of the built-in tax account.

Now it’ all started to make sense to me.

I’d like to think of it as a spare tire, and we are asking too much from it at the moment.

[ATMCAssociates]

I think I have agreed on the same day about the solution Manager has, though few suggestions were made.

Kind Regards

Sampath Kumara

Partner

ATMC Associates

[sharpdrivetek]

thank you for the clarification @lubos