Restructure chart of accounts

(0) Share

Report

Posted on by Community Member

We acquired another company that is heavily involved in billing customers for services. I am working on merging our two companies into one chart of accounts, but keeping them as two separate entities in GP.

We want to be able to analyze revenue by entity, customer, or region of the customer. For example, we want to see how much we billed Fabrikam in total, but also want to see how much we billed Fabrikam-Las Vegas, Fabrikam-Denver, etc. The way I want to build the COA structure is: AAA-BBBB-CCC-DD

AAA = department or customer region

BBBB = GL account

CCC = customer

DD = entity

Do you see any issues with this GL structure above?

My biggest concern is I plan on re-using numbers in Segment AAA. For example, 123 for the first segment AAA may be the Las Vegas region for customer Fabrikam, but 123 for the first segment AAA may be the Phoenix region for customer AB Tools.

Thanks.

*This post is locked for comments

I have the same question (0)

All responses (3)

Answers (1)

Verified answer

MattPaulen 6,912 on at

Like (2)

Report

Just my 2 cents from having assisted with several restructuring of Chart of Accounts. If possible, I would keep the AAA ID's consistent across entities. It'll typically make things simpler in regards to reporting instead of having to specify the entity/customer/region combo every time. If Las Vegas is always 123 across all entities then you only need to specify the region when looking for Las Vegas. This may lead to gaps in the region codes for entities and/or customers but that shouldn't be a big deal. 3 digits should give you alot of breathing room.

You could even do something where AAA's that begin with a 1 are out west, 2's are midwest, 3's are Southeast, 4's are Northeast, etc. This would add the ability to report on a region as a whole. For example if you wanted to see a P&L for out west for all customers you could just use the 1?? wildcard designation and it would automatically pull all the west regions in. Granted, these examples would be that you would have less than 100 sub regions per region.

Was this reply helpful? Yes No
Suggested answer

Beat Bucher GP Gee... 28,058 Moderator on at

Like (2)

Report

Hi John,

I agree with Matt... we use GP with multiple companies and have setup GP over 10 years ago.. initially there were only 3 physical GP company databases, but there were more entities. Some of the minor branches were kept in the main company (HQ) and the distinction was made based on the Account segments. This is what we use :

AAAAA = Main GL Account

BBBB = Region code (or country)

CCC = Department

DDD = Product family code

For the Region Code (BBBB) we used the 1st number to separate the global regions in the world (i.e. 1xxxx was used for the Americas, 2xxxx for Europe, and so on). The DDD product family code was used in the earlier years as the company wanted to track revenues by products, but about 2 years ago after the company was aquired, it turned out that this wasn't much used, so PSTL helped us to reduce by over 30% the number of total GL accounts by merging the last segment to bring it down to 000.

At some point in time, we added new companies in GP to segregate the transactions for the branches, as it was a problem to report the financials in Multi-Currency out of the main company with Management Reporter 2012. We kept the accounts with the other regions because of some inter-co entries, but mainly that has been moved to new companies. The new ones have followed the same segment schema, making it easier to report in MR2012. Our reporting tree has up to 12 different branches when it comes to generate consolidated reports.

Hope this helps to start some brain storming.

Was this reply helpful? Yes No
Community Member on at

Like (1)

Report

few thoughts. 1) Having Entity on the end - if you are closing retained earnings by Entity, will force you to also close by Customer 2) does the customer belong to a specific Entity, 3) Are you relying on users to accurately code sales? 4) Customer ID is already attached to postings from Sales Module. The Customer Segment is redundant (field is ORMSTRID where SOURCDOC indicates Sales (there are many)). Additionally, how would you stop a user from booking an invoice to customer 1 (customerid), but use customer 2 Customer Segment Code? 5) Are expenses using the same code structure -including Customer Segment Value? All of the above thoughts also apply to previous comments about consistency in Region application. the right analysis tool could provide Sales level analysis, along with financial performance.

Was this reply helpful? Yes No