You are correct in your example and yes, it should feel wrong. That workaround is totally fine though and most small companies will do something like how you have described.
In your example, using multidimensional accounting you could book one entry to "Travel Meals Lodging" GL account and have the dimensions "Program", "IRS Exempt", "T&E Subcategory". This creates a one-to-many relationship with the transaction instead of having 4+ GLs. You could book to one GL "Travel Meals Lodging" with the dimension values "Program Non Exempt", "Non IRS Exempt" and "Meals". You could design the dimensions differently, but I am just trying to give you an example.
No, I am not aware of an SMB package that supports this. It probably exists but from what I understand it makes the database more complex (cube?) and everything more compute intensive on the reporting side. Thought I haven't looked into it much - if you find anything, let me know.
I have a couple projects running on GnuCash, but it doesn't support dimensional accounting. Netsuite would work, but anything Oracle is a hard sell in my space.
Do you recommend any resources for implementing dimensional accounting? Articles? Example schemas?
If you are coming from GnuCash, Netsuite is probably overkill and/or out-of-budget. Even if you had the resources, I would probably consider Sage first.
Multidimensional accounting is in effect supplementing the GL with additional data. For each transaction, you could have a database table that adds a column for each new dimension. Or if you don't prefer a relational structure, a json object attached to each transaction. Outside of setting that up, the problem probably becomes the user experience ie. how do you add that information at the same time as posting your entry?
If you wanted an even more "hacky" way, you could embed the data into the memo/description field or another available field. Unfortunately, the off-the-shelf reporting would not be useable because it would not know how to parse the embedded data.
Unfortunately, the multidimensional accounting space is dominated by enterprise accounting system offerings. So I don't know of any resources for implementing it outside of switching to those systems.
In your example, using multidimensional accounting you could book one entry to "Travel Meals Lodging" GL account and have the dimensions "Program", "IRS Exempt", "T&E Subcategory". This creates a one-to-many relationship with the transaction instead of having 4+ GLs. You could book to one GL "Travel Meals Lodging" with the dimension values "Program Non Exempt", "Non IRS Exempt" and "Meals". You could design the dimensions differently, but I am just trying to give you an example.
No, I am not aware of an SMB package that supports this. It probably exists but from what I understand it makes the database more complex (cube?) and everything more compute intensive on the reporting side. Thought I haven't looked into it much - if you find anything, let me know.