ERP Business Analyst in Austin

Live music venues and promoters: settlement night as a process

Austin calls itself the Live Music Capital of the World, and behind every show at a club on Red River Street, a theater downtown or a larger hall outside the center sits a settlement: the moment after the show when the venue or promoter and the artist's representative agree who is owed what. The calculation pulls together ticket revenue from the ticketing platform, service charges and taxes that pass through, the deal terms in the artist's contract, production and marketing costs, and sometimes merchandise and bar sales.

Many venues still settle from a spreadsheet template, then re-key the result into accounting days later. As a business analyst I map that flow step by step: where each figure comes from, who checks it, which deal types the venue uses, how cash and card advances are recorded and what the signed settlement must show. I then define what belongs in the ERP and what stays in the ticketing and point-of-sale systems.

The requirements usually cover a show or event record that collects revenue and costs, deal terms stored as structured data rather than free text, approval before payment, and a link from each settlement to the payable or receivable it creates. Tax treatment of ticket sales and artist payments is confirmed by your accountant; the requirements make sure the system holds the data they need.

Game studios: milestones, storefront payouts and project costs

Austin has a long-standing game development community, from small independent teams in shared studios to larger developers working for global publishers. Their revenue rarely looks like an ordinary sale. A studio under a publishing agreement delivers builds against milestones, waits for acceptance and then invoices. A studio that self-publishes receives periodic payout reports from digital storefronts, often net of platform shares, refunds and regional taxes, in formats that can change without notice.

In workshops with the producer, the finance lead and the studio head, I document how milestones are defined, who signs off a build, what happens when a publisher rejects a deliverable and how payments are matched to milestones. For self-published titles, I specify how payout reports are imported, which dimensions they must be broken down by, such as title, platform and region, and how they reconcile with bank deposits.

Studios also need costs tracked by project and sometimes by feature or phase, because accountants may ask which development costs relate to which title and stage. Whether any of those costs are capitalized is a decision for your accountant, not for the system. My job is to make sure time, contractor invoices and outsourced art or audio work carry the right project codes from the start, so the question can be answered from data instead of reconstructed later.

Statewide associations: dues, conferences and education credits

Because the Texas Capitol is in Austin, many statewide trade and professional associations keep their staff here. Their work follows a recognizable cycle: membership renewals, a yearly conference with exhibitors and sponsors, continuing education courses that members need for their licenses, and busier periods when the Legislature meets.

Much of this runs on a membership database, often an association management system, with accounting in a separate package. The trouble starts at the boundary. Dues may cover a period that crosses the fiscal year, conference revenue arrives months before the event, sponsors buy packages that mix exhibit space, advertising and tickets, and course payments need to be tracked by program. Finance staff end up reconciling exports by hand.

As the business analyst I map each revenue stream from the member's first action to the ledger, decide with your team which records stay in the membership system and which postings the ERP needs, and write requirements for deferral schedules, restricted funds and event accounting that your auditor and accountant then confirm. If the association also runs a foundation or other separate entities, the requirements cover how shared staff and costs are allocated between them, and which reports each board expects to see.

The apps you keep, and what the ERP must receive from them

Austin organizations, whatever their sector, tend to run on several specialist platforms before they ever consider an ERP: ticketing and point-of-sale at a venue, storefront dashboards and project trackers at a studio, a membership system and event registration at an association. These tools are usually good at their jobs, and replacing them is rarely the goal. The requirements question is what the ERP should receive from each of them.

For every interface I document the direction of data, the level of detail and the timing. A venue may only need nightly summaries by show and revenue type, while a studio may need payout lines per title and territory. I also record who owns the mapping when a new product, show type or membership tier appears, because interfaces often break when the source system changes and nobody updates the mapping on the other side.

Each interface also gets reconciliation requirements: which report proves the systems agree, who reviews it and what happens when they do not. These details sound small, but they decide whether finance trusts the ERP. They also make vendor proposals easier to compare, since integration effort is often the least visible part of an estimate. The ERP integration service covers how those interfaces are then built.

Testing with a sold-out show, a rejected build and a late renewal

Requirements only earn their keep if they are used to test the system. I write acceptance scenarios from real events in your calendar rather than from generic test lists. For a venue, a scenario might run a sold-out show with a split deal, a cancelled date with refunds and a night where the venue sells the artist's merchandise. For a studio, it might cover a milestone rejected and resubmitted, a storefront report that arrives with corrections and a contractor invoice split across titles. For an association, it might be a member who renews late, registers for the conference at the member rate and claims education credits in the same week.

Each scenario lists the requirement numbers it proves, the data needed, the expected result and the person who signs it off. During testing I record what passed, what failed and which failures are configuration fixes rather than genuine gaps. That record becomes part of the evidence for go-live and a reference for your team afterwards.

The analysis happens remotely, over video calls, in shared files and in a tracker your team already uses, with visits by arrangement if a walk-through at the venue or studio would help. For the wider deliverable set, see the US ERP business analyst page and the Austin ERP consultant page.