{"id":4403,"date":"2026-09-09T05:29:52","date_gmt":"2026-09-09T05:29:52","guid":{"rendered":"https:\/\/www.greytrix.com\/blogs\/acumatica\/?p=4403"},"modified":"2026-09-09T05:29:53","modified_gmt":"2026-09-09T05:29:53","slug":"https-www-greytrix-com-blogs-acumatica-3","status":"publish","type":"post","link":"https:\/\/www.greytrix.com\/blogs\/acumatica\/2026\/09\/09\/https-www-greytrix-com-blogs-acumatica-3\/","title":{"rendered":"Segmented Keys and Sub-Account Structure in Acumatica"},"content":{"rendered":"\n

The one design decision you do not get a second run at<\/em><\/p>\n\n\n\n

A prospect showed me their proposed sub-account structure about two weeks before go-live. Five segments: branch, department, location, product line, cost centre. It looked thorough. Somebody had clearly put a weekend into it.<\/p>\n\n\n\n

I ran the arithmetic on the whiteboard. Their five segments allowed something north of forty thousand theoretical combinations. When we went through it properly, the number they would actually post against came to roughly ninety.<\/p>\n\n\n\n

That is the trap, and almost everybody walks into it from the same direction. You come from a system where the account string was the only place to put anything, so you put everything there. Acumatica <\/a><\/strong>does not work that way, and building it as though it does costs you for years.<\/p>\n\n\n\n

Here is the uncomfortable part. Nearly every other configuration mistake in Acumatica is an afternoon of rework. This one is a data conversion and a broken set of prior-year comparatives.<\/p>\n\n\n\n

What a segmented key actually is<\/h2>\n\n\n\n

Worth being precise, because the term gets used loosely. A segmented key is a template describing how identifiers are built for a particular type of record. Sub-accounts are the one everybody talks about, but the same mechanism sits behind GL accounts, business accounts, inventory items, warehouses and locations. You configure them all on the Segmented Keys form.<\/p>\n\n\n\n

For sub-accounts specifically, you have up to thirty characters to play with. Split that into as many segments as you like, or leave it as one undivided string if your business genuinely does not need the breakdown.<\/p>\n\n\n\n

The GL Account key is a different story. It caps at ten characters, which surprises people who arrive with a twelve-character account number from their legacy system and assume they can carry it across. Find that out at the design stage rather than during migration. Each segment gets a length and a validation setting. Validate it, and users can only pick from a list you maintain on the Segment Values form. Leave it unvalidated and the segment is free-form, which is faster to set up and a reliable way to end up with three spellings of the same department.
<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

What you can change later, and what you cannot<\/h2>\n\n\n\n

This is the section worth reading twice, because the boundary is not where most people assume it is.<\/p>\n\n\n\n

Things you can do<\/h3>\n\n\n\n

You can bolt a new segment onto the end of the key. Your existing sub-accounts pick up a blank trailing segment, and you go back and fill it in. Not painless, but not a rebuild either. Transactions carrying the old combination follow the change through.<\/p>\n\n\n\n

You can add segment values whenever you like. You can also deactivate values that have fallen out of use, and this is the nicer behaviour of the two: the value stops being available for anything new while staying intact on the historical records that already carry it.<\/p>\n\n\n\n

And you can merge sub-accounts by shifting the balances onto the one you want to keep and switching off the rest.<\/p>\n\n\n\n

Things you cannot do<\/h3>\n\n\n\n

Remove a segment. Once transactions have posted against the affected sub-accounts, the system stops you, and there is no clever way round it.<\/p>\n\n\n\n

What catches people out is that an empty tenant does not save you either. Sub-accounts get referenced all over the system long before anybody posts anything: posting classes, AP and AR preferences, customer and vendor records, stock items, projects, company settings. Every one of those references has to be stripped out first. I have watched someone try this on a tenant with two hundred posting classes and give up around lunchtime.<\/p>\n\n\n\n

Lengthening a segment once records exist will also throw an error at you. So the rule is roughly this: adding at the tail is survivable, and everything else is a project with a budget attached. Treat it as a one-way door with a narrow side gate.<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

The over-segmentation trap<\/h2>\n\n\n\n

Back to the client with forty thousand combinations.<\/p>\n\n\n\n

The reason people over-segment is that they are thinking of the sub-account as the only dimension available. In Acumatica it is one of several, and most of the others are better at their jobs.<\/p>\n\n\n\n

So before any segment goes into the design, one question: does Acumatica already track this natively?<\/p>\n\n\n\n

Branch is the clearest case. Acumatica\u2019s own multi-branch documentation tells you not to create a sub-account segment for branches. Branch already sits on every transaction, and branch visibility is handled through roles and restriction groups. Encoding it into the sub-account duplicates data that is already there and multiplies your combination count for nothing.<\/p>\n\n\n\n

Projects are the same argument. If you are tracking project costs, that is what Project Accounting is for, with project tasks underneath it. Make a project a sub-account segment and you have signed up to maintain a segment value for every project the company ever takes on.<\/p>\n\n\n\n

Items, employees, customers, vendors, cost codes \u2014 all first-class dimensions already. None of them belongs in the key.<\/p>\n\n\n\n

What legitimately earns a segment is a cut of the P&L with no native home, a stable meaning over several years, and a small closed set of values. Department is the textbook case. Product line sometimes qualifies. Fund, if you are in the nonprofit world.<\/p>\n\n\n\n

Two segments handles most mid-market businesses. Three if there is a real reason. Four should require somebody to stand up and defend it.<\/p>\n\n\n\n

One assumption to unlearn<\/h2>\n\n\n\n

In Acumatica, accounts and sub-accounts are independent of each other. There is no native concept of “these sub-accounts are valid for that account”. You maintain a list of accounts and a list of sub-accounts, and the system will happily let someone post revenue against a manufacturing sub-account.<\/p>\n\n\n\n

If you came from Dynamics GP or similar, this feels wrong, and people spend the first month looking for the screen where you tie them together. It does not exist. Restriction groups get you part of the way, but it is not a clean substitute. Build the expectation into user training early rather than fielding the same question forty times after go-live.<\/p>\n\n\n\n

Sizing the segments<\/h2>\n\n\n\n

Small decisions here, long consequences.<\/p>\n\n\n\n