Kenya

https://localizations.manager.io/summary-view?FileID=S2VueWE

@EPR_Capital why there are so many balance sheet accounts in Chart of Accounts for Kenya? Please do not create arbitrary Chart of Accounts structure in country template unless there is national standard that must be followed.

The chart of accounts and the codes are issued by the Kenya Revenue Authority. Although there is no requirement for one to adhere to the standard chart of accounts while preparing/maintaining their management accounts, they must convert their accounts into this formated chart of accounts in order to file their annual income tax returns to the authority.

The authorities came up with this standardized format based on the requirements of Kenyan Laws as far as accounting is concerned, i.e The Income Tax Act and the Companies Act.

So these are not arbitrary accounts. I am intending to create the P&L accounts as well in accordance with the Kenya Revenue Authority so kindly advice.

OK, in that case that’s desirable what you are doing.

One question though. In Manager, there is no concept of group codes in chart of accounts. But you seem to be adding some suffixes. Are you saying groups in chart of accounts have also assigned code that must be shown on financial statements? Also, why the code is so long.

image

What looks like a group code is just a means to show how totals for a group are arrived at. Note that there is no concept of adding new totals on the balance sheet side, but there is on the P&L side.

They are not necessary and do not add any value at all. A plain title will suffice and I will make the changes today. Here is the list of chart of accounts from Kenya Revenue Authority. Please note the use of the long codes and advise.

Chart of Bsheet.pdf (76.6 KB)
Chart of P&L.pdf (285.6 KB)

I agree this is a real problem and I support your efforts to find a solution. The issue is actually much more general than just the annual tax return in Kenya though, similar requirements apply in many jurisdictions.

However while I support your endevour to find a solution, I do not think the approach taken is optimal. The reasons

  • For an accountant who’s main business contact is helping prepare the annual tax return it would be very convenient (but boarding on doing them out of a job). However that is not the main use of electronic records for a business owner.

  • Tax authorities specify requirement to monitor their tax income stream, not for effective business management. There is usually alternative COA designs which reveal far more useful information for daily business management.

  • Tax authorities regularly change their coding requirements. It is appropriate a tax accountant is familiar with the intricacies of current and past requirements however the same does not apply to a Manager user entering daily or weekly accounts.

A better solution in my opinion is a country specific localisation which enables mapping of a users chart of accounts to the tax authorities chart of accounts via custom fields on the chart of accounts. As described here Custom fields for chart of accounts - #5 by Patch For Australia that requires two custom fields with 39 localisation defined values.

The business owner is then able to design a chart of account with the optimal structure for their business requirements. A report at tax time then reformats the accounts to that required by their tax authority.

The tax accountants job is then just to

  1. tag the business accounts to the tax authority requirement.

  2. Sort the few entries not covered buy mapping from the users to tax authority account groupings

  3. Advise modifications to the users COA of task 2 accounting suggests a savings opportunity.

Having predetermined COA does not prevent someone from deleting or creating accounts as they wish.

Also I think is the right way to handle this because~

  1. Other software e.g QuickBooksTM for example allows one to select an industry they are operating in, upon which a bespoke set of accounts is created. The default accounts can be deleted, renamed and reclassified to suit the user’s needs. When creating a new account, one can easily follow the existing coding.

  2. Taxes in Kenya are on a self-assessment basis and most small businesses file their tax returns without necessarily hiring a professional. Only businesses with turnover of over Ksh. 50,000,000 (USD 500,000) are required to hire a tax agent/external auditor.

  3. Presentation of accounts for management purposes can be tweaked at the reports section to come up with desired management information. So we are killing three birds with a single stone i.e making management accounting easier and standardized, complying with Companies Act as well as complying with Income Tax Act.

  4. The chart of accounts developed by Kenya Revenue Authority, despite being meant for tax purposes, is prepared based on Kenyan Laws (which all businesses in Kenya must comply with) The Kenyan Companies Act laws specify basic requirements of the books of accounts. The COA helps users comply subconsciously. Manager is made for Micro, small and medium sized businesses with users who might not be necessarily accountants.

In my opinion, creating custom fields is complicating the process and making it harder for an ordinary user to operate the software.

I also think that in future, one will need to select a country upon which customizations will be applied according to the country. Programmers can make it possible for one to choose whether they want the customizations to include a customized chart of accounts or not.

I have seen you grappling with projects tab. My suggestion is that just the way you have come up with country specific customizations, it would be important for you to also come up with industry-specific customizations. It looks like projects would easily fall under NGO specific industry ( A huge group that focuses on UN and other non governmental accounts.

There is need to cater for manufacturing industry (which will give pre-eminence to assembly accounting and process costing), Schools (which might give emphasis on customer groups and customer(student) management, Hospitals which may require flowchart kind of specialists user rights management and emphasis on billable time/cost centering, Aviation Industry which may require complex costing procedures, Governmental Institution that may require robust budgeting procedures and accounting procedures, Banking/microfinance industry that may require robust user management and may involve processing and reporting of a high number (millions) of transactions. etc.

My view of Manager as a solution is that it has already solved over 90% of basic accounting equation and by extension has solved 90% of what any user with accounting needs may require. The remaining 10% dissatisfaction is as a result of industry-specific needs.

Manager is Made small business and Aviation,Banking are large Industries and manager Possibly Do not able to handle The Accounting of these Industries.

Use production order , Inventry write off tabs 

And Stages of Manufacturing for manufacturing industry.

Budgets are Already on P&L and Requested for Budgeted balance sheet is already made.

1 Like

Use Custom Fields and Divisions for Cost Centres and Design user permissions as per Req. And Advanced user permissions are already Requested Role Based Access Control.
Billable exp and biilable tabs are there to Handle billable time and exp.

Make A custom fields for Customer(Students) groups
Or
Use Diffrent Control Accounts for customers.

Multiple localisation can already be added to a Manager business. Loading a country and business specific localisation sounds conceptual reasonable to me.

@Patch in my Opinion Business Specific Localization is just increasing Complexity of Software.

1 Like

I fully agree with @Omnipotent.inc. Plus I think most industry specific packages are forcing users to follow less than optimal setup given their specific needs, not to mention the clutter with all of the unused accounts as a result.

However, I can see a point with what @EPR_Capital is suggesting, maybe if selecting an industry setup package enables certain tabs and creates a few basic P&L accounts, like say, you select manufacturing and this enables all inventory tabs and creates a few general production P&L accounts – that wouldn’t be so bad.

It all depends on how it’s being handled:

  • If it’s going to be like “here’s a good place to start” and from their you can tailor a setup that suits individual business needs, then I’m all for that.

  • But if it’s like “this is how things are supposed to be done” or “here’s a mishmash of accounts from every possible setups imaginable” then no.

Industry-specific localizations is very premature to discuss when Kenya doesn’t even have general VAT return created in localization yet.

There is no such thing as a general VAT return in Kenya. Instead, every VAT registered company in Kenya is required to maintain a VAT control account. At the end of the month, a company needs to export the contents of the VAT control account (sales and purchases invoices) and input them into a VAT return template spreadsheet provided by Kenya Revenue Authority (Attached).

The problem is extracting the data that is required to be imported. Some information e.g Amount before VAT in an invoice cannot be extracted? The format of sales invoices list and the purchases invoice list is attached.


When the two CSV files are imported into the VAT Return template, the VAT payable/claimable is computed (ties with the balance of the VAT control account). The VAT return template is then uploaded into the Kenya Revenue Authority itax system in a process known as “filling the monthly VAT return”

See how the VAT Control Account is set up.

The Australian “Single Touch Payroll Worksheet” report transformation creates a csv file.
Perhaps similar report functionality could be used for in the Kenya localisation.