The Remittance Advice No field exists because invoiced doesn't mean paid, and promised doesn't mean remitted. For anyone managing live music bookings at volume, the gap between invoice sent and remittance confirmed is where cash flow problems quietly develop until they become urgent.
When the Spreadsheet Stops Being Enough
A music booking operation running twenty or thirty events a month across multiple venues and performers eventually hits the ceiling of what a spreadsheet handles well. The invoice is in one tab. The performer's contact details are in another. Whether the deposit cleared for the spring corporate gig is in a third tab, and whether anyone cross-referenced it against the SAP Concur reference number from the client is — probably — in someone's email.
The structural problem is that bookings have multiple stakeholders, multiple financial touchpoints, and a time dimension that creates cascading dependencies. A booking confirmed three months out has a different status from one confirmed three weeks out with a deposit still outstanding. A performer who's done eight gigs for you has a different relationship from a first-time booking. Neither of those distinctions is visible in a flat list.
What Two Linked Libraries Actually Change
The template runs two libraries: the bookings master and a linked Musicians directory. The Musicians entries field on each booking links to the performer database — name, musician class (Solo/Duo/Band), specialty (Acoustic, Backing Tracks, Female Vocalist, Tribute Artist, Open Mic), and full contact details including business and mobile numbers. This means you never duplicate performer data across bookings. One performer record, referenced from as many booking entries as needed.
The practical payoff comes when you're building a shortlist for a booking. A private function wants acoustic guitar, available on a specific Saturday in June. Filtering the Musicians library by Specialty: Acoustic and cross-referencing against booking dates with Musician Class: Solo narrows the list without checking a separate spreadsheet or scrolling through a contacts app. The performer intelligence lives inside the booking system, not alongside it.
The Invoice Type multichoice (BACS or SAP) and Payment Type multichoice (PreAuth Deposit, Cash, Cheque) define the payment architecture for each booking. Corporate venues running SAP Concur purchase order workflows need the SAP reference captured from the start. Public house bookings may pay cash on the night. Both need different follow-up actions and different remittance timelines, and having both typed — not free-texted — means you can filter outstanding SAP-invoiced bookings separately from BACS payments.
The Cancellation Record That Protects You
The Cancelled / Declined section — Cancellation Date and Reason — is one of the least glamorous and most professionally useful parts of the template. Cancellations happen. What matters is that the reason is documented and dated, not reconstructed from memory when a venue queries a deposit return or a performer asks about a cancellation fee.
A reason field that's actually populated creates an audit trail for disputed deposits. A venue that cancels two days before the event versus two weeks before has a different contractual position, and the date-stamped cancellation record makes that position clear without anyone having to find the original email thread.
At a hundred bookings logged over a season, the database tells you which venues have the highest cancellation rate, which performer specialties are most frequently rebooked, and which months have outstanding remittances past thirty days. That data doesn't require a separate analysis — it comes from filters on data that was already entered at booking time.