Income tax payable

One of the largest debts incurred by a business entity throughout a trading period is the income tax payable on profit. To assist with financial planning and investment decisions it would be helpful if Manager can accrue income tax payable throughout the trading period.

Manager would need to facilitate the following functions to enable the calculation of income tax payable:


  1. Income tax rate (flat rate or marginal rates) applicable to the entity for separate legal entities taxed in their own right.
  2. Income tax rates applicable to the proprietors of flow-through entities.
  3. Entry of taxable income derived from other sources and tax withheld on that income to ensure correct marginal rates of income tax are applied to the profit earned by proprietors of flow-through entities.
  4. Unpaid income tax from a previous tax period.


  1. Expenses not tax deductible.
  2. Income not taxable.
  3. Adjustments for timing of tax deductions and possibly the add-back of movements to selected balance sheet account balances.
  4. Allow for income or expenses that are excluded from calculating income tax payable until gains or losses are realized.
  5. Government incentives such as for every $1 spent on innovative research and development an income tax deduction of $1.50 will be allowed.

Forgive me for the essay, I did not know how to summarise my thoughts.

The income Tax Payable module will be a big project.

I would propose a tool that can suggest something close to chargeable income but not compute and accrue income tax. For example, a tool that can assist in calculating “Profit before Tax depreciation and Amortization and other special items (Financial costs, Carry forward losses, repairs and improvements per tax laws, tax incentives, foreign exchange gains/losses)”

@lubos This is how I think we could start:

Tools required.

Reporting Categories for Accounts (Special Accounts, Ordinary accounts, other accounts)

Income example.

Create a Reporting category for “Ordinary Taxable income.” This category will show the Ordinary taxable income for the specified reporting period by adding the net movement for all income accounts under the Ordinary taxable income reporting category.

We can take it a step further by assigning categories to balance sheet accounts (Real Accounts) to include them in the report transformation report. This is because some revenues may be treated differently under accounting standards but are still considered taxable by tax authorities. That category can be called “Deferred according to accounting standards but considered taxable Incomes.” The report will only include what has entered the account (credits) during the specified period. When such “inflows” are finally treated as earned under accounting standards, they must be moved into an income statement account with a reporting category that will not be added for taxable income computation to avoid double counting of taxable revenue. For Example, a customer deposit (for long period rents) that meets the definition of taxable income by the tax law. The liability accounts (regular or special accounts) must be given a “Taxable income” reporting category to report credits or increments in that account for the period.

Other revenues may be deemed non-taxable by the tax authorities, resulting in a timing difference.


Put such a revenue account in the “Non-Taxable” category, but the associated receivable account (customer account) for such income in a reporting category like “Revenues Taxable Upon Receipt.” The idea is that the report will pull “Receipts” transactions from the customer account for that period and report them as taxable income in the report transformation. A reporting category that only reports cash transactions from a linked account will be required.

I am aware that realisation does not only come in the form of a cash receipt. For example, you could use a journal entry to offset a receivable against a payable to realise a receivable. That is correct, but this suggestion will necessitate a method that ensures the workflow is not impacted even when such offsetting is required:

Create a different cash account for such offsetting transactions. To realise the asset through offsetting, create a receipt from the cash account and a payment from the same account to offset the liability. This will ensure that the suggested workflow is not broken. It also ensures that the books stay clean (limit journal entry use).

Example for Expenses.

The same workflow applies to managing expenses with timing differences.

Put asset accounts (Regular and special accounts) containing deferred expenses deemed taxable in the current year by the tax authority, for example, under the category “Deductible Expenses Treated as deferred in Accounts.” When such expenses are moved into the income statement, they should be moved into accounts under a “Non-deductible” reporting category to avoid using those expenses for tax calculations twice.

Put Payable accounts with temporarily unallowed expenses under a “Expenses not allowed but deductible Upon Payment” reporting category to account for timing differences due to cash payment (when tax authorities only allow expenses paid in cash). When the suppliers are paid, the report will pull such payments (net cash transactions) on the payable account (for the specified period) as realised and show them as deductible expenses in the Report Transformation.

There are many things you can do to handle situations if such improvements are introduced to Reporting categories and Report transformations.

Enable the use of Accounting Profit for A specified Period and accounts in Report Transformations.

Others may simply want to use report transformations to adjust the accounting profit for the year to arrive at the desired figure for calculating income tax payable. For example, they will reverse the impact of depreciation and non-deductive expenses on profit.

If this concept is implemented, a user who attempts to use and rely on such a report may be required to create numerous accounts, depending on the complexity of income tax computation in their jurisdiction. For example, if a supplier provides more than one service and the characteristics of the services provided by the supplier have different tax treatment, you may need to create two accounts for the supplier.

The concept is not yet clear in my mind and may contain some flaws, but I have a strong feeling that the solution for Income Tax computation will come from Report transformations if enhancements such as the one here are added: Add support for opening and closing balances - ideas - Manager Forum

Example of the proposed report transformation

Personally, I think income tax calculations and provision in Manager is a dangerous road to travel. Think of the resources Intuit devotes to annual software for a single country. Support would be impossible.

That’s a 100% true. That’s why I believe Manager should only hand the end users the keys to the jeep.

That’s not possible at the moment since transformations aren’t available for the everyday user. This means the localization teams need to be experts on 190 countries tax laws, times the number of industries, times the number of special tax considerations, times the number of different COA architectures … it’s quite a rabbit hole.

If on the other hand Manager makes this as an open easy to use tool for users and their tax consultants to tailor a custom COA and reporting categories that suit their tax position, then I’m all in for it.

I think it is already easy to construct a chart of accounts tailored to your local tax requirements. I have done that myself. I think that qualifies as what you refer to as the keys to the Jeep. I don’t think Manager should go any further.

Agree but the tax authority groupings and totals are different to what is required to meaningfully monitor business activity. Which is why I would find it valuable to generate reports in more than one grouping. My preference is via COA custom field support (together with a custom report or report transformation) as that provides a readily achievable but also general solution. For an example see Custom fields for chart of accounts - #5 by Patch

That is why I stated that we must concentrate on developing a tool that can calculate something close to chargeable income (e.g. Profit Before Tax Depreciation, Government incentives, Carry Forward Losses, etc). In other words, I propose a tool that will do the majority of the work for you by putting together taxable income and deductible expenses already in the account.

Lubos has stated that report transformation and reporting categories will return for all users, regardless of whether they are using a business template (localisation) or not. I don’t think there should be an income tax localisation project, but the tools should be available for users who want to do so in their business.

Some users would like their chart of accounts to assist them with management accounting. My proposal can easily assist in the generation of a customized report to handle tax computation for such users.

This sounds interesting. The solution lies with report transformation.

With all of this said, I want to emphasise that Manager should not be turned into a tax software, but income tax computation support should be a high priority because it will, if it is not already, be a key battleground for accounting software producers.

No the solution relies on

  • Ensuring the COA is sufficiently fine grained / specific to enable the classification required for business administration as well as for tax reports (control accounts or COA groups can be use to recombine accounts for normal business reports where that level of detail is not required)

  • Custom field(s) provide the Tax authority naming and identify which COA accounts are reported under each of the tax authority heading.

  • After all accounts (& thus transactions) are labelled / grouped as required by the tax authority, the reportable totals are easily generated by a custom report. A simple report transformation could also be used to provide closer correspondence between the Manager report and Tax authority form (with the same figures as shown in a basic custom report). A report transformation may also allow assigning a single custom field to each COA account but that would involve encoding the hierarchy in the report transformation.

That’s basically replicating reporting categories function using custom fields. Why not just have a separate reporting category type for COA?

I’m confused.

  • Where in Manager do I go to define “a separate reporting category type for COA”?

  • If you mean I could construct my COA to generate the tax office’s report then I’m not keen on that as most of the year I want to know and understand what my business is doing.

  • Looking further I see there is now a Setting → “Cash Flow Statement Groups” which enables creating custom Financial reporting groups under three headings. I will have to experiment to see if I can fit the ATO groupings in these, which may achieve part of what I want (I would use three sort levels [custom fields] and two sort orders if I implemented what I really want with custom fields).

I think @Ealfardan is saying you do not need Custom Fields to get Reporting Categories to use COA for Report Transformations.

1 Like

Why have you quoted Reporting Categories? Or to ask the question another way

By the way, allocating tax authority reporting categories to Manager accounts must be done by the user defining the Manager businesses COA. It can not by any future report transformation as this allocation will always be business specific.

Looking at this it is unlikely to work as it is purely for cash flow. However an equivalent structure for “P&L alternate reports” may work. Ideally the option of creating multiple alternate COA structures (ie the ability to create groups, sub totals and ordering these heading but not the actual accounts).

@Patch I believe we are going too far. We need to wait and see what approach Lubos will take to get us an Income Tax tool when the time comes before we continue the discussion about whose idea is the best. He might even come up with an entirely new workflow.

Looks like I had misinterpreted @Ealfardan and @Abeiku comments. I had assumed I was missing an existing Manager feature where alternative Reporting categories could be defined for the COA. But as it is a possible future feature, I will stop looking for it in the current software.

By the way, imo

  • COA custom fields would probably be a comparatively simple program addition and provide the greatest user flexibility.

  • The facility to add “Alternate custom COA structures” (consisting of Groups & subtotals) would probably provide the cleanest and easiest to use solution long term.

  • Supporting multiple “Alternate custom COA structures” would be very valuable to maintain old reports, should the tax authority introduce changes invalidating a prior reporting structure. It would also enable reports optimised for other applications and reporting entities. Ideally implemented by the “Alternate COA Structure” report allowing selection of which “Alternated COA Structure” is used (as well as normal parameters such as date ranges, Accrual/Cash basis etc)

Gosh it was hard enough getting the GST or Vat right for all the countries and I am still not sure if NZ is right see below I seem to remember it being wrong and I dont know if it was corrected see what they are asking below .I too changed my chart of accounts to accommodate what I needed then I put the profit into our IRDs tax calculator for sole trader or company or partnership etc and got the tax amount to pay and its break down. I even put the income and the PAYE already earned and paid in there. Not very well but client got the idea. Because IRDs IR10 is not the same as any of managers reports I only use reports for the client and manually enter the data I need into IRD tax returns.