The Daxko chart of accounts I'd build from scratch

Most YMCA charts of accounts I see have somewhere between 400 and 1,000+ active GL accounts. They got that way the same way every time: someone asked for a report, a new account got created to feed it, and nobody ever went back to clean up. Five years later the COA is unreadable, branch rollups don't reconcile cleanly, the budget process takes weeks because every line needs an owner, and the audit prep PBC list is twice as long as it needs to be.

The fix isn't a software switch. It's a structure decision that gets made — or doesn't get made — at setup, and then quietly determines how hard every month-end will be for the next decade.

Here's the structure I'd build if a Y handed me a clean slate in Daxko Accounting.

The five-segment architecture

XX-XX-XX-XXXX-XXXXXX

Segment	Digits	What it tracks
Fund	2	Restriction class
Branch	2	Physical location
Department	2	Functional area
Natural account	4	Type of revenue or expense
PCS code	6	Specific program or grant

Each segment does exactly one job. When a segment starts encoding information that belongs in a different segment, the structure breaks down — and that's where most COAs go wrong.

Segment 1: Fund (2 digits)

• 01 — Unrestricted
• 02 — With Restrictions (temporarily restricted)
• 03 — Permanently Restricted

ASU 2016-14 collapsed temporarily and permanently restricted into a single category — net assets with donor restrictions — for financial statement presentation. I still track them separately at the GL level, and the reason isn't nostalgia.

Permanently restricted net assets still require their own disclosure in the notes. If the underlying detail isn't preserved in the GL, the disclosure becomes a reconstruction exercise every audit — pulling from contribution agreements, board resolutions, and historical fund statements to recreate what should have been a query.

The other reason: budgeting. The operating budget lives in fund 01. Fund 02 and fund 03 hold activity that's restricted, episodic, and often unbudgetable — endowment income, restricted contributions, releases. Keeping them in separate fund segments means the finance director can pull a clean operating P&L without filtering out endowment swings or restricted contribution timing.

Segment 2: Branch (2 digits)

One branch, one code. Nothing exotic.

If the Y has two branches today and might add a third, leave room. 01 and 02 for active branches, room to add 03 later. Don't use the branch segment to track anything other than physical location — if you find yourself wanting to add an "Association Office" branch code, that's actually Administration in the department segment.

Segment 3: Department (2 digits)

• Administration / Corporate
• Fundraising / Grants
• Childcare / Camp
• Membership
• Aquatics
• Other Programs

Six buckets covers nearly every YMCA I've worked with. Aquatics earns its own department because it's a major revenue and risk center at almost every Y — lifeguard staffing, pool maintenance, and swim lesson revenue are large enough to warrant standalone visibility. The temptation is always to add more beyond this: Sports, Wellness, Group Exercise, Personal Training, Active Older Adults. Resist.

The point of the department segment is to give you a clean functional-expense view — the kind that maps to the 990 statement of functional expenses without manual reclassification. Six buckets does that. Twelve buckets makes the reclass worse, not better, because now you're allocating against more lines.

Two exceptions are worth making beyond the six:

1. A genuinely large program category — if camp or before/after school care is 30%+ of the budget on its own, it earns its own department code.
2. A grant-driven separation requirement — if ELOP or 21st Century Community Learning Centers grants require functional segregation at the department level, the funder's reporting requirements override the structural elegance.

Outside those two exceptions, hold the line at six.

Segment 4: Natural account (4 digits)

This is where COAs go to die.

The natural account names the type of revenue or expense. Not the program. Not the location. Not the funding source. The type.

Personnel side, this should be obvious:

• Salaries
• Payroll taxes
• Workers' comp
• Retirement / 403(b)
• Health insurance

Those roll up to a Personnel subtotal that's easy to read at every level — branch, department, program.

Program side is where most COAs explode. The pattern I see constantly:

• 5210 Program Supplies
• 5211 T-Shirt Supplies
• 5212 Camp Supplies
• 5213 Food Supplies
• 5214 Sports Equipment
• 5215 Art Supplies

That's six accounts doing the work of one. The right structure is one Program Supplies account, and the PCS code tells you which program it belongs to. If you need to know how much was spent on t-shirts for the basketball program, that's a report filtered by PCS code on the Program Supplies natural account — not six standalone accounts.

The same principle applies on the revenue side. I'll get to that under PCS.

Segment 5: PCS code (6 digits)

PCS is the most underrated segment in a Y chart of accounts. Done well, it's where 80% of the analytical value lives. Done poorly, it's where the whole structure unravels.

The rule I follow: PCS codes lead with the department code.

Childcare/Camp is department 02, so the first childcare PCS code is 020001. The second is 020002. The third is 020003. Membership is department 04, so membership PCS codes start with 04.

This does two things at once: it makes the PCS code self-documenting (you can read a PCS code and instantly know what department it belongs to), and it forces a discipline at the point of code creation (creating a new code means consciously deciding which department it lives under).

What gets a PCS code:

• Individual childcare sites under Childcare/Camp
• Individual sports programs (basketball, volleyball, swim team) under Other Programs
• Group exercise, personal training, swim lessons under Membership
• Specific grants under Fundraising/Grants or under the program they fund
• Specific fundraising events (Gala, Golf Tournament, Annual Campaign)

Each program at the PCS level typically generates five or six P&L lines: program fees (revenue), salaries, payroll taxes, retirement, program supplies, occupancy. That's enough to tell you whether the program covers its direct costs without descending into noise.

The four PCS mistakes I see most often

Mistake 1: A new PCS code every year for the same fundraising event

Pattern: Gala 2023, Gala 2024, Gala 2025. Each gala gets its own PCS code so finance can "track it cleanly."

The problem: year-over-year comparison becomes manual. You can't run a five-year trend on Gala revenue without summing across five PCS codes. Worse, donor lists and sponsor patterns get fragmented across multiple codes, which makes development reporting harder than it needs to be.

The fix: one Gala PCS code, forever. Use date filters in reporting to slice by year.

Mistake 2: Using the natural account to encode something the PCS code already tells you

Pattern: a natural account called Childcare Preschool Fees (4231).

The natural account should be Program Fees (4200, or whatever number you assign). The PCS code identifies it as preschool. If you encode the program into the natural account, you've duplicated work and made the COA bigger than it needs to be — and now the PCS code is doing nothing for revenue.

The fix: one Program Fees natural account on the revenue side. The PCS code does the slicing.

Mistake 3: Splitting program supplies by type at the natural account level

Covered above under natural accounts. The natural account is Program Supplies. The PCS code is the program. Filter, don't fragment.

Mistake 4: Adding a new account every time someone asks for a new report

This is the meta-mistake that creates all the others. Someone in development wants to see grant revenue split out by grantor — so a new natural account gets created for each grantor. Someone on the board wants to see Aquatics broken out — so a new department gets added. Someone in operations wants to track t-shirt spend separately — so a new natural account appears.

The COA is the structure. Reports are views on the structure. If a report needs a slice that doesn't exist yet, the answer is almost always a filter, a grouping, or a custom report — not a new account.

This requires a single point of accountability for COA changes — someone (the controller, the finance director, the outsourced finance partner) who has authority to say no to "can we just add one more account?" Without that, the COA grows like weeds.

What this gets you

A Y running this structure has:

• A finance committee package that ties out — branch rollups reconcile because branches are segmented, not buried in account numbers. Functional expense views reconcile because departments are segmented.
• A 990 you don't have to reconstruct — the statement of functional expenses lines up to the department segment. Restricted vs. unrestricted lines up to the fund segment. Program service revenue lines up to PCS codes within the Other Programs department.
• A budget process that runs in days, not weeks — fewer accounts means fewer lines to populate, fewer ownership disputes, and fewer "what does this account actually capture?" conversations.
• An audit prep PBC list that's half the size — less detail to support, fewer reclasses to explain, cleaner trial balance.

A before/after example

A mid-sized Y I worked with came in with 612 active GL accounts. The department segment had 14 codes because every program area had been broken out. The natural account section had 320+ lines, including a separate account for nearly every kind of supply, food, equipment, and license they purchased. PCS codes were inconsistent — some started with the department code, some didn't, and several were named with dates ("Camp 2022," "Camp 2023") that should have been one program.

After restructuring:

• Fund segment: 3 codes (unchanged)
• Branch segment: 4 codes (unchanged — they have four branches)
• Department segment: 6 codes (down from 14 — the standard six, no exceptions needed)
• Natural account segment: 178 codes (down from 320+)
• PCS codes: 94 codes (down from 140, mostly by consolidating year-tagged events and grant-by-grantor codes)

Total: 285 active accounts, down from 612. Same financial reporting fidelity. Cleaner trial balance. Audit prep took three weeks less the following year.

The setup sequence

If you're doing this from scratch — new Y, new Daxko Accounting implementation, no legacy COA to migrate — the order matters:

1. Fund segment first. It's the most stable and the easiest to define. Once it's set, it almost never changes.
2. Branch segment second. Also stable. Define it before you build anything else because every transaction will carry a branch.
3. Department segment third. This is the first one that requires real judgment. Resist the urge to over-segment.
4. Natural account segment fourth. Build the personnel section completely first — those accounts are universal. Then revenue. Then non-personnel expenses. Keep going back to the principle: type of revenue or expense, not program, not location, not funder.
5. PCS codes last. PCS codes get created as programs exist. Don't try to pre-build PCS codes for programs that might launch — wait until they exist.

If you're cleaning up an existing COA, the sequence is different. The hardest part of cleanup isn't designing the new structure — it's mapping the old accounts to the new ones, deciding which historical detail to preserve, and migrating prior-year comparatives. That's a separate post.

What this isn't

This isn't a Daxko Accounting setup tutorial. There are configuration steps inside Daxko — segment definitions, account number formatting, validation rules — that I haven't covered here. The Daxko Training Database and the Daxko Accounting Guide cover the mechanics. This post is about the structural decisions that should be made before you sit down to configure anything.

It also isn't a one-size-fits-all template. Every Y has quirks — a major grant that demands its own functional segregation, a programs portfolio that doesn't fit cleanly into five departments, a branch acquisition with a legacy COA that has to be reconciled. The structure above is the default. Variations should be deliberate, defended, and limited.

The point isn't the specific numbers. It's the discipline: each segment does one job, the natural account names the type, the PCS code names the program, and the COA stays as small as possible for as long as possible.

That's the difference between a COA that helps and a COA that haunts.