The four-sheet Excel workbook that runs a small agency

You've probably downloaded three "travel agency accounting excel" templates off the internet by now. Each has a neat enquiry tracker or a pretty booking calendar, and none has a PAN column, a TCS column, or a way to tell if you've already paid that hotel for this exact block. So you built your own, in pieces, over eighteen months, held together with tabs nobody remembers the purpose of.

A five-person agency doesn't need a template mill. It needs four sheets, built around how bookings, payables and tax actually move through an Indian agency, not what a generic template site thinks a "travel spreadsheet" should look like. This post gives you all four, column by column, with the formulas and two rules that keep the whole thing from rotting by month three.

Why four sheets, not one workbook

An enquiry register, a booking register, a vendor payable sheet, and a receipts-and-refunds sheet: a lead moving toward a sale, money coming in, money going out to a supplier, and the tax paperwork behind both.

Most downloadable templates collapse this into one sheet with a generic "notes" and "amount" column. That breaks the moment you need to answer three real questions at once: has this client's TCS been collected, has this hotel been paid for this block, and did we issue a GST document for that receipt.

Four sheets, linked by one thing: a booking reference. Every payable and every receipt ties back to a booking.

The enquiry register: the columns that stop a lost lead

An enquiry register makes sure a lead never goes quiet without someone noticing. The columns aren't about the trip, they're about the follow-up.

Date | Source | Destination | Pax | Travel Dates | Owner | Next Action Date | Status

• Date: when the enquiry came in, to measure speed to first reply.
• Source: Instagram, Google, referral, walk-in. Shows which channel actually converts.
• Destination: what they asked about, for season pattern-spotting.
• Pax: headcount, since a 2-pax and a 12-pax enquiry need different quoting effort.
• Travel Dates: the trip window, separate from the enquiry date.
• Owner: the staff member responsible. Even in a two-person team, an unowned row goes unfollowed.
• Next Action Date: the single most important column. Without it, "I'll follow up later" becomes "I forgot."
• Status: new, quoted, negotiating, won, lost.

This sheet exists to stop the most common failure: a lead gets one quote on a busy day and dies from silence.

The booking register: the columns that carry money and compliance

The booking register is where an enquiry becomes a paying commitment, carrying your PAN and TCS exposure.

Booking Ref | Lead Pax | PAN | Package Value | TCS | Advance Received | Balance Due Date | Departure Date | Status

• Booking Ref: a unique code (say, KMR-2607-01) every other sheet links back to. This is what makes the workbook one system, not four disconnected lists.
• Lead Pax: the primary traveller's name.
• PAN: mandatory for any package with an overseas leg. RBI's LRS Master Direction requires PAN for any remittance under the scheme, regardless of amount, as of August 2026 (RBI); LRS rules are revised by circular, so recheck if it's been a while. No PAN on file, no clean outward remittance.
• Package Value: the total sale value, before TCS.
• TCS: a Tax Collected at Source amount applies on overseas tour packages, collected at the time of payment, on a tiered structure (TaxGuru). The current threshold and rate are reported inconsistently across advisory sources as of August 2026, so don't hardcode a figure here. Confirm the applicable rate with your CA before billing each package.
• Advance Received: cumulative advance collected so far.
• Balance Due Date: separate from the departure date.
• Departure Date: used for the days-to-departure formula below.
• Status: confirmed, part-paid, fully paid, cancelled.

A visible TCS column forces the check at billing time, not at year-end reconciliation, after the client has already flown and there's no clean way to recover a shortfall.

The vendor payable sheet: the one that stops double-payment

A vendor payable sheet answers one question fast: has this supplier, for this booking, been paid.

Supplier | Service | Booking Ref | Cost | Paid | Due Date | Voucher Issued (Y/N)

• Supplier: the hotel, transporter or DMC name.
• Service: what's being paid for (room block, vehicle, permit), since one supplier can appear multiple times against one booking.
• Booking Ref: the same code from the booking register. Without this anchor, a second staff member with no visibility into what's already gone out can authorise the same payment twice.
• Cost: the agreed payable amount.
• Paid: a simple Y/N flag, kept current, not inferred from bank statements later.
• Due Date: distinct from the client's balance due date.
• Voucher Issued (Y/N): whether the confirmation voucher has actually gone to the supplier. A paid booking with no voucher issued can still fall through at check-in.

The receipts and refunds sheet: what "GST document issued" actually means

The receipts sheet tracks money in and the tax paperwork it triggers, and its most-skipped column is the one that matters most.

Date | Mode | Receipt Voucher Number | Against Booking | GST Document Issued

• Date: when the money actually landed, not when it was promised.
• Mode: UPI, bank transfer, cash, card.
• Receipt Voucher Number: a sequential number, so every receipt is traceable.
• Against Booking: the booking ref this payment settles.
• GST Document Issued: a yes/no flag, but behind it sits a real decision. Tour operator services default to 5% GST under heading 9985 with no input tax credit, though operators can opt into 18% with ITC instead (TaxGuru). A valid GST invoice needs an invoice number and date, both parties' GSTIN where registered, place of supply, HSN/SAC code, taxable value and the GST amount (ClearTax), generally issued within 30 days of the service. "Y" here should mean that invoice went out, not that a receipt was texted on WhatsApp.

Settle your invoicing approach once, using the method for deciding between a 5% and 18% package invoice, and this column stops being a per-booking guess. Hand this sheet and the booking register to your CA each period as the source for the return-side entries; the chart-of-accounts and journal-entry version of this system is worth building alongside it.

Three formulas worth building in

Balance due (D = Package Value, F = Advance Received):

=D2-F2

Days to departure, so a close date with an unpaid balance is visible at a glance (H = Departure Date):

=H2-TODAY()

Exposure by supplier, totalling what's still unpaid to one supplier across every booking:

=SUMIFS(VendorPayable!D:D, VendorPayable!A:A, "Hotel Name", VendorPayable!E:E, "N")

Example: Six bookings run through one Srinagar hotel this July, ₹40,000-₹65,000 each. The exposure formula, filtered to Paid = N, gives you a live total owed without opening six rows and adding it up by hand.

Two hard rules that keep this system alive past month three

Rule one: one row per booking, forever. Never delete or overwrite a cancelled or completed booking's row to reuse for a new client. Add a status value instead. Reuse a row and your booking-ref links to the other sheets break silently, right when you need them most: at tax time, or when a client disputes a payment from months ago.

Rule two: dates must be stored as actual date values, never as text. Typing 12/08 in a way Excel reads as text looks identical on screen but breaks every formula above without an error message. Balance-due sorts wrong, days-to-departure errors out, and nobody notices until a departure is missed. Quick check: real dates right-align by default, text left-aligns, so dates hugging the left edge are broken. A firmer test is =ISNUMBER(A2), which returns TRUE for a real date.

What a spreadsheet cannot do, so you know when to stop

Excel is a record. It's not a system that stops mistakes from happening.

• No clean multi-user editing: two staff open the same file, and one person's changes silently overwrite the other's.
• No nudges: Next Action Date only works if a human remembers to check it.
• No tamper-evident trail of who changed a value, when, or what it was before.

These aren't reasons to abandon the workbook while your team is small enough that everyone knows what's in it. They're the point where a growing agency needs something beyond a shared file anyone can quietly edit. The seven signs your operation has outgrown Excel are worth checking against first.

The short version

• Four sheets, one system: enquiry register, booking register, vendor payable sheet, receipts and refunds sheet, linked by one booking reference.
• Enquiry register needs an Owner and a Next Action Date on every open row, or leads die from silence.
• Booking register needs PAN (mandatory for any overseas remittance) and a TCS column confirmed per booking with your CA, never a hardcoded number.
• Vendor payable's Booking Ref column is what stops the same supplier being paid twice for the same block.
• GST document issued means an invoice meeting the mandatory-fields checklist actually went out, not a WhatsApp receipt.
• Build in three formulas: balance due, days to departure, and exposure by supplier.
• Never delete or overwrite a booking row (use status instead), and always store dates as real date values, never as text.