Your fundraising hierarchy is the tree your gifts roll up into: the purposes and designations your development team picks every time a gift is entered. Two small fields on those records, category and report code, get filled in during implementation and then ignored. That’s a missed chance. Both are user-defined lists, so you can make them carry a second way of grouping your money that the hierarchy’s parent-child structure can’t show by itself.
Below are some practical ways to use them, plus the guardrails that keep them from turning into junk drawers.
Why the hierarchy alone isn’t enough
A hierarchy answers one question well: “what does this money belong to?” Education programs sit under Education, the new gallery fund sits under Capital, and so on. But finance, the board, and grant writers each want to slice the same gifts differently. The board wants restricted versus unrestricted. Finance wants something closer to its own reporting lines. A grant writer wants everything that supports, say, school programs, which might live under three different branches.
You could rebuild the tree every time someone asks a new question, but that breaks historical reporting. Category and report code let you add a second and third lens without moving anything.
Decide what each field means first
The single most useful thing you can do is assign each field one job and write it down. A common split:
- Category describes the nature of the fund: unrestricted operating, temporarily restricted, permanently restricted/endowment, capital.
- Report code describes where it shows up in outside reporting: a board dashboard line, an annual report section, or a finance roll-up.
Whatever you choose, don’t let one field mean two things. If half your report codes describe restriction status and half describe board lines, nobody can filter on them reliably and you’re back to exporting to a spreadsheet and sorting by hand.
Uses that tend to pay off
Restricted vs. unrestricted at a glance
Putting restriction status in category means any revenue query can filter or group on it. When finance asks how much unrestricted money came in last quarter, you add one field to an existing query instead of maintaining a list of designation names that someone has to keep current.
Board and annual report lines
Boards rarely want your full hierarchy. They want five or six lines. Assign a report code for each line (for example “Annual Fund,” “Education,” “Animal Care,” “Capital,” “Endowment,” “Other”) and map every designation to one of them. Now the board summary is a query grouped by report code, and it stays consistent year over year even when you add new designations.
Cross-branch themes for grants and campaigns
Some funders care about a theme that crosses your tree, like youth access or conservation. If you aren’t already using one of the fields for something else, a code for the theme lets you pull every relevant designation in one pass. Be careful here: this only works if the theme is stable. If it changes every grant cycle, use a selection or a saved query instead.
A bridge to the general ledger
Some organizations use report code as a loose pointer to how finance groups revenue, which makes reconciliation conversations shorter. Treat it as a reporting aid, not a replacement for your actual GL mapping. Your posting setup should still drive what lands in the ledger.
Cleanup flags
A temporary category such as “Inactive – review” can mark designations you plan to retire. It’s easy to find them later, and you aren’t deleting anything with gift history attached.
Guardrails
- Keep the lists short. If a code table grows past what fits on one screen, it’s probably doing two jobs.
- Give one person ownership of the code tables. Values added on the fly by whoever’s entering a new designation are how you end up with “Endowment,” “Endowmt,” and “Endow Fund.”
- Fill in every record. A blank code silently drops gifts out of grouped reports. Run a query for hierarchy records with no category or report code after any setup work.
- Don’t duplicate campaigns or appeals. If the question is “which solicitation raised this,” that belongs on the gift’s appeal or campaign, not on the fund.
- Document the definitions somewhere staff will actually see them. A one-page table of each code and what qualifies is enough.
Check what your database actually exposes
Altru databases differ depending on when and how they were set up, and which hierarchy levels carry these fields, and how they appear in query and reports, can vary. Before you redesign anything:
- Open a few purposes and designations and confirm where category and report code appear on the record.
- Build a test revenue query and look for those fields in the designation or hierarchy section of the field list. If you can’t group revenue by them, you’ll want to know before promising the board a new report.
- If a standard report doesn’t respect them, ask Blackbaud support whether it can, rather than assuming.
- Make changes on a handful of records first, run your queries, and only then update the rest.
Quick answers
Will changing a category or report code change historical gifts?
Those fields live on the hierarchy record, not the gift, so reports that read them will typically reflect the current value, including for older gifts. That’s usually what you want, but note the change date in case someone compares against an old printed report.
Should I add a new hierarchy level instead?
Only if the grouping is truly about what the money belongs to. If it’s just another way to report on the same funds, a code is cheaper and doesn’t disturb your history.
