One Data Set, Three Income Figures: The Hidden Role of Semantic Layers in Historical Reenactment Accounting

Three Answers, One Question

Ask a simple question at any historical reenactment society: "What was our net income from last month's event?" You'll likely get three different numbers—one from the treasurer, one from the quartermaster, and one from the membership coordinator. Each person has a valid reason for their figure, but the confusion can tear a society apart.

I once saw a medieval fair committee argue for an hour over whether "income" meant the cash taken at the gate, the pledges from membership dues, or the amount that actually cleared the bank after refunds. Nobody was lying. They were just speaking different dialects of the same language.

The problem isn't the data. The problem is that we haven't agreed on what we're measuring.

Why the Same Ledger Produces Different Numbers

Every historical group keeps records. The membership database tracks who paid dues. The event coordinator logs ticket sales and refunds. The treasurer records actual deposits and expenses. These records might even live in the same spreadsheet or database—but that doesn't mean everyone interprets them the same way.

Take a single transaction from a reenactment event:

• Transaction ID: 10086
• Amount: $120
• Status: 3 (meaning "completed")
• Timestamp: 2026-07-12 14:30

To the database, this is just a row. It knows the amount is a number and the status is an integer. But it doesn't know if that $120 is a membership renewal, a camping fee, or a donation to the cannon crew. The field might be named "revenue," but that label doesn't tell you which business rule applies.

The Silent Assumptions Behind Every Number

In historical organizations, the same event can generate income in several ways: gate tickets, vendor fees, food sales, donations, and membership dues. Each category has its own logic. The treasurer might count only money that has cleared the bank. The event coordinator might count all tickets sold, including those later refunded. The membership secretary might count pledges that haven't been paid yet.

So when someone asks, "What was our income?" the real question is: which income? The answer depends on what you're trying to decide. Are you planning next year's budget? Then you want committed funds. Are you reporting to the board? Then you want recognized revenue. Are you checking whether the event made a profit? Then you want net cash received.

Beyond Spreadsheets: How Historical Groups Manage Definitions

Most historical societies handle this with tradition and memory. The treasurer has a rule of thumb. The event organizer keeps their own tally. The board reviews a summary report. It works—until someone leaves, or the group grows, or an auditor asks for a breakdown.

Then the cracks show. A new treasurer interprets "income" differently. A volunteer builds a new spreadsheet with a different formula. The same event yields different numbers, and nobody can explain why.

This is where a semantic layer—a concept borrowed from data engineering—can help. A semantic layer is a set of agreed-upon definitions that sit between your raw data and your reports. It says: "When we say 'net event income,' we mean ticket sales minus refunds and credit-card processing fees, for the event date, not the payment date."

For a historical group, that might sound like overkill. But even a simple version can prevent chaos.

Building a Simple Semantic Layer for Your Society

Start by listing every metric you actually use. For a reenactment society, that might include:

• Event attendance
• Ticket revenue
• Membership dues collected
• Net income after direct event costs

For each metric, write down the exact rule. What counts? What doesn't? What time period? What data source? For example:

• Ticket revenue: All paid tickets for the event, minus refunds, using the event date, pulled from the ticketing system.
• Membership dues: All dues payments received during the calendar year, regardless of membership period.
• Net income: Total revenue minus direct event costs (rent, insurance, porta-potties, etc.).

Then assign an owner. One person—usually the treasurer—should be the final authority for each definition. That doesn't mean they make up numbers, but they are the one who says, "This is how we define it, and here's the logic."

From Definition to Report: Making It Work

Once you have definitions, the next step is to make them repeatable. If you use a spreadsheet, create a hidden sheet that contains the rules. If you use a database, create a view that encodes the logic. If you're using a BI tool, define the metrics there.

The key is that the definition lives in one place, not in someone's head. When a new volunteer asks, "How do I calculate net income?" you point them to the definition. They don't have to guess.

Let's say your group wants to know last month's net income from the historical fair. With a semantic layer, the system—or the person—knows to ask: "Which metric? Net cash received, accrued revenue, or committed pledges?" Then it pulls the right numbers from the right sources, applies the filters (last month, specific event, specific region), and returns a number with context.

That context matters. A report that just says "$1,000" is useless. One that says "$1,000 net cash received for the July fair, based on ticket sales minus refunds, as of August 1" is trustworthy.

The Takeaway for Historical Groups

Historical reenactment is about preserving the past, but that doesn't mean we have to manage our finances like it's 1849. A little bit of data discipline can save hours of argument and build trust.

You don't need a data warehouse or a dedicated IT team. You just need to write down your definitions, agree on them, and stick to them. Your treasurer will thank you. Your board will thank you. And when someone asks, "What was our income?" you'll all give the same answer.