Add support for opening and closing balances

[Abeiku]

@lubos Report transformation for tax codes provide information on transactions that occurred within the specified period (selected time), but it does not provide information on the tax amount that must be paid, and this is because there may be carried forward VAT assets (carried forward or as Starting Balance) or liabilities to be considered in the period. My suggested solution is to allow the inclusion of the following in Report Transformations

1. Account Closing balance. The closing balance of an account(s) will be included in the report transformation to help compute the tax to be paid in cash at the end of the specified period. The date for the closing balance will be the same as the report’s chosen end date.

2. Account Starting Balance. The Starting balance of an account(s) will be included in the report transformation to help compute the tax to be paid in cash at the end of the specified period. The date for the starting balance will be the same as the report’s chosen Start date.

Use Case.

In some jurisdictions, customers are to withhold some or all the VAT amount on supplier’s invoices and pay to the tax office. It is called Withholding VAT. The supplier will disclose this VAT asset (credit) in the VAT returns provided the tax credit certificate has been received. Report transformations can include such asset (Account Closing balance) in the report to correctly compute the VAT to be paid to the tax office.

Many jurisdictions may allow a person to pay all or some of their tax liabilities due to the state later because of working capital issues, therefore, there will be a credit starting balance on the tax payable account for the current period. Others may also have output tax in excess over input tax for the prior period or may have overpaid taxes. Manager can include such balances (Account Starting Balance) in Report transformations to compute cash payable to the tax office for the current period. This will also be useful for those who have migrated to Manager with starting tax payable balances.

The second problem is that users can no longer choose accounts for tax liabilities when creating tax codes. In my opinion, users should be allowed to select the liability account they wish for tax code components. Choosing separate liability accounts for tax code components provides a second source of verification for tax code balances right on the summary screen. Also, this will be necessary to put the above suggestion into effect when working with multiple rates for tax codes.

Before

After

@Ealfardan what do you think of this?

[Ealfardan]

@Abeiku

Account Starting Balance. The Starting balance of an account(s) will be included in the report transformation to help compute the tax to be paid in cash at the end of the specified period. The date for the starting balance will be the same as the report’s chosen Start date.

Although this information isn’t readily available in report transformations but a similar effect can be achieved using 0% or 100% tax codes (both have their pros and cons) to make the opening balance visible in the current period tax return.

An example Journal to transfer the opening balance is this*

In the case of Bahrain, tax liabilities aren’t carried over from one return to the next but tax credits do but it’s essentially the same thing – I am just relabeling an existing balance as opening balance using a tax code. I find this method to be more advantageous because:

• It’s more deliberate,

• It forces the user to review the “Tax Summary” and “Tax Reconciliation” reports – which are essential to ensure accuracy,

• It avoids mismatching opening balances for whatever reason

and:

• It enables the transfer opening balances from multiple accounts

Having said that, I wouldn’t mind the convenience of having the opening balance available for use in transformations.

A similar approach can be used for relabeling closing balances.

@Abeiku

The second problem is that users can no longer choose accounts for tax liabilities when creating tax codes.

When did that happen? I’m not sure if this counts as an improvement because how would users maintain multiple tax accounts?

Please @lubos, give us back the ability to setup multiple tax accounts.

Edit: @Abeiku, just enter a tax rate and account selection will appear. How did we both miss this?

[lubos]

@Ealfardan

Having said that, I wouldn’t mind the convenience of having the opening balance available for use in transformations.

This is the correct way to approach this. There have been quite a few changes to report transformations in the past month and this specific thing is rather easy to implement now.

[Ealfardan]

Looking forward to see how this works.

[Abeiku]

@Ealfardan

just enter a tax rate and account selection will appear. How did we both miss this

Oh I see, I didn’t try. The field used to pop up automatically

[Abeiku]

@lubos

There have been quite a few changes to report transformations in the past month and this specific thing is rather easy to implement now.

Not to be pushy @lubos but can you give some idea on the possibility of introducing this and the new challenges delaying this project.

Thanks

[Abeiku]

@lubos I’m here again to ask about this feature. You previously mentioned that it wouldn’t be a complex addition. I’m not requesting that it be implemented immediately, but I’d like to understand why we haven’t seen any progress on it yet.

Some potential customers are asking about these capabilities, and we need to be able to give them something concrete. This feature wouldn’t only be useful for tax computation, think about the kinds of reports it could help generate, since it can show the net movement on accounts.
If you add support for total debits and total credits within this feature, users could leverage it to produce very important accounting reports.

[lubos]

@Abeiku I will be removing report transformations from the system and country-specific reports will be simply extensions which will have unlimited possibilities since they are coded.

When I made report transformations, the idea was to create code-free interface for constructing country-specific reports but advancements in AI have kind of turn that approach on its head. With the latest technology, you can convert text instructions into code.

I’m still in the process of improving extensions as they are not quite there yet to replace report transformations but it’s going to happen soon.

[Abeiku]

Good to hear this, but I hope it doesn’t introduce new complexities to non-coders. Report Transformations, if you understand it well, is a very powerful tool that accountants can use to generate customized reports to their exact preferences.

For example, the tax reports I created using Report Transformations for the Ghana Localization closely mimic the Ghana government’s online and physical tax forms for taxpayers. I had full control over what appeared in the reports, with 100% accuracy.

I’m not sure what the new version will look like, but in my opinion, the existing tool was already performing very well, it just needed a few additional features.

[Abeiku]

@lubos I am moving this topic from the Ideas section because I do not believe it is practical for any application to fully handle these requirements on its own, considering the complexities involved in tax administration. Furthermore, this was originally proposed as an enhancement to the Reporting Categories and Report Transformations features, both of which have now been retired.

In practice, tax accounting is rarely straightforward. Numerous adjustments imposed by tax authorities can affect tax liabilities and the related reports at any point in time. Attempting to force all such complexities into the application itself would, in my opinion, be an inefficient use of time and development resources.

I believe a more practical approach is to use external worksheets, such as spreadsheets, alongside reports generated from Manager for these purposes. The most important requirement is the ability to generate reliable and detailed reports for the relevant reporting period.

That said, I consider the Reporting Categories and Report Transformations tools to have been extremely powerful features. They should have been preserved in some form, accompanied by comprehensive documentation and guidance for users who wish to build highly customized reports. Let us also not forget that many users may never need to use Extension Reports (and extension tax codes) if they are able to build their own customized reports that complement their internal accounting workflows.

[Ealfardan]

I wholeheartedly agree with everything you just said, including how it’s mostly futile to try to capture every possible tax return line within a single report.

However, I do think that the original idea is now easier to implement since Extensions can now look into multiple reports such as Tax Summary as well as Tax Reconciliation and include the opening/closing balance in the localized tax report.

So I don’t understand why this idea was scrapped now that it’s easier to implement.

Also, I fully endorse this:

@Abeiku

That said, I consider the Reporting Categories and Report Transformations tools to have been extremely powerful features. They should have been preserved in some form, accompanied by comprehensive documentation and guidance for users who wish to build highly customized reports. Let us also not forget that many users may never need to use Extension Reports (and extension tax codes) if they are able to build their own customized reports that complement their internal accounting workflows.

[Abeiku]

I understand your point, but I still believe this idea is unlikely to materialize. The concept itself is sound; however, the underlying platform that would have supported it, namely Report Transformations, has already been retired.

Moreover, in practice, many businesses transfer balances from the VAT Payable account at the end of a reporting period into a VAT Settlement account in order to keep the VAT control account clean and easier to reconcile. All items affecting the final amount payable are moved into the VAT Settlement account, including VAT-withholding balances and other related debit or credit adjustments.

Once all relevant journal entries have been posted through the various tax management accounts into the VAT Settlement account, the remaining balance represents the actual VAT liability to be settled in cash.

@Ealfardan

I fully endorse this

Yes, because many users may be reluctant to depend solely on built-in tax tools, particularly in environments where tax laws and administrative requirements evolve frequently, while software implementations of those changes may not occur immediately.

@Lubos, perhaps these tools deserve reconsideration. In jurisdictions such as Ghana, VAT regulations and tax return formats are subject to frequent revisions. Almost every electoral cycle introduces amendments to the VAT framework, and additional changes can arise even within the tenure of a single administration.

For this reason, flexible reporting tools are extremely valuable, as they allow users to adapt their reporting structures to local regulatory requirements without having to wait for official software updates.

If these features were restored, I would be willing to prepare a detailed guide demonstrating the workflow from tax code creation, through Reporting Categories, and ultimately into Report Transformations for users who want to build their own reports and tax codes. I previously developed similar guidance materials for Ghana, particularly on handling VAT complexities associated with imports, such as differences between business exchange rates and customs exchange rates.

In my view, maintaining the flexibility Report transformation will, in the long run, help shield the software from constant pressure by users demanding immediate updates for every new tax law or regulatory change.

The Tax code related reports in Manager are already quite robust. The true strength of Report Transformations, however, lies in their ability to empower users to design reports that closely replicate the official tax return formats prescribed within their respective jurisdictions, while also accommodating reports tailored to their unique accounting workflows and operational requirements.

So, I suppose I will move it back to the Ideas section and wait for Lubos to make the final decision.