Travel agency accounting software: what your books need from bookings

Travel agency accounting software has to do what a general ledger cannot do alone: turn bookings that keep changing (amendments, cancellations with a fee kept, suppliers who keep part of the cost, agencies paying in another currency) into balanced vouchers, per business entity and currency, that your accountant imports into the package they already use. What is usually missing is that feed, not a new ledger.

Why a general ledger alone does not fit a travel business

An accounting package is good at what happens after a fact is known. A travel booking is a fact that keeps moving.

• A sale is not final. A stay is amended, one room of three is cancelled, a late-cancellation fee is charged and later waived. Each is a separate event on a separate day, and a closed month must not be rewritten by any of them.
• There are two sides to every booking. What the agency owes you and what you owe the hotel or the transport company. They move independently: the agency cancels inside the free window, the hotel still keeps a night under its own terms.
• Money arrives in other currencies. An agency billed in US dollars by a business whose books are in euros owes dollars. The rate at the sale and the rate at payment are rarely the same.
• One group, several companies. An inbound operator with an office in two countries trades through two legal entities, each with its own tax number, number series and fiscal year.

Re-keying all of this by hand is where the errors come from. The job of the booking side is to hand over every event as a voucher, already balanced, so the accountant reviews rather than types.

The records that must reach your books

In iTravel's Portal, each recorded fact becomes exactly one voucher, dated on the day it belongs to on your account's clock. This is how the main events map:

Three rules make the files tie. A request or a hold accepted later is a sale of the day it was accepted, so a filed month never changes. A supplier bill is frozen at what the supplier billed then; a later change is its own bill or debit note on its own day. And each agency's balance in the books equals the statement it sees in the portal. How that account works day to day is covered in agent credit and prepaid wallets, and the supplier side in supplier payables for DMCs.

Packages post to their own sales and cost ledgers, named the way your accountant's chart of accounts needs them.

Tax: rules you define, per business entity

Tax is where software is most tempted to choose for you, and it should not. Your tax position depends on where you are registered, what you sell, to whom and where the service happens, and you or your adviser decide it.

What to require instead is the means to express your rules. In iTravel each book (each business entity) carries its own tax rules in Settings, Tax: a rate or a fixed amount; charged on the price, on the margin or per unit; added on top or included; your rounding and your wording; conditions on the kind of service, the customer type and the place of supply; rules stacked as a group; and margin schemes. A "test a sale" panel shows what a rule produces before you rely on it.

Two details matter at month end:

• Disagreements are shown, not settled. If two of your rules match the same sale, or a sale your book can make matches none, the editor says so with an example. It never picks one for you.
• A margin tax never prints its amount. A printed margin tax would let the customer work your margin back out, so the paper states that the scheme applies, in your wording.

If your prices include tax, say so on the book and the export splits each amount into its net and the tax lines your rules define, rounding each tax line and letting the net absorb the remainder so every voucher balances. If they do not, nothing is split. Withholding at payment follows rules you define in the same way.

Exporting to Tally, Xero or QuickBooks

The accounting export (Manage, Reports, Accounting) writes one business entity and one currency per file, over any period you choose:

The files use ISO dates, so no package can misread day and month, and amounts in each currency's own digits. The journal writes every line twice: in the voucher's currency and in your book's currency at the rate the sale froze. Where no rate was frozen the base columns stay blank; they are never filled at today's rate.

You name the ledgers. Every name starts as a value in your book's language until you type your own, and an agency or supplier that already has a different name in your books (a Tally alias, a Xero contact) can be mapped to it. Files that carry costs can be downloaded only by people with the right to see costs. If you also run Vouchers or the CRM, their invoices, receipts and instalments reach the same files.

Closing the month: lock dates, revaluation and the accountant's pack

• Lock the period. Each book has one lock date. Everything dated on or before it is closed: no new entry, no change. A correction is a new entry in the open period. Closing and reopening are separate rights, and reopening needs a typed reason; both are recorded.
• Know when a filed month changed. Each export is recorded with a fingerprint of its vouchers. Re-export a closed period whose content no longer matches and the page tells you what changed before anything downloads.
• Revalue open foreign balances, if you choose. Run the month-end revaluation by hand, or switch on monthly runs per book, and open foreign-currency balances are valued at a closing rate you type, or else the platform's daily rate. The unrealised difference posts on the last day and reverses on the first day of the next month.
• Hand over the pack. The accountant's pack is read from the same vouchers as the export: trial balance, tax summary, receivables and payables ageing, exchange gains and losses, and withholding, each as CSV.

A worked month end

The figures are illustrative, and tax is left out to keep them readable. Your books are in euros. Agency A buys in euros on 30-day terms; Agency B buys in US dollars.

Read it at the close. Agency A owes 1,100 EUR (2,000 + 500 − 500 + 100 − 1,000), which is what its statement says, and it is not yet due. Revenue is 2,100 EUR from Agency A and 1,000 EUR from Agency B. The tour's cost is 80 EUR, because the operator kept 80 of 400. The 20 EUR gain arises because a member of staff typed what the bank actually credited; without that figure the platform's rate for the day is used, and with no rate at all no difference is computed rather than a guessed one.

The fee keeps its own line because the cancellation policy frozen on the booking decided it, and the dollar sale stays in dollars on Agency B's statement, which is why one currency per agency matters. You download the euro file and the dollar file, your accountant imports both, the trial balance from the pack agrees, and you lock the month. A refund dated in that month a week later is refused; it is entered in the open month instead.

Checklist before your first month end

• One book per legal entity, each with its currency, fiscal year and number series.
• Tax rules entered per book, tested on a sample sale, with no disagreement left showing in the editor.
• Ledger names that match your accountant's chart, with aliases for agencies and suppliers already in your books.
• Rights decided: who may download exports, see costs, close a period and reopen one.
• For Tally, the ledgers file imported once before the first vouchers file.
• For each foreign-currency agency, the habit of typing what the bank actually credited.
• Revaluation decided per book: by hand, monthly, or not at all.
• A dry run first: export last month, import it into a copy of your books, and compare the trial balance before you lock anything.

If you are still writing the specification for a portal, the accounting rows sit alongside the rest of the B2B portal requirements.