What changes when the agency works in Argentina
Up to a point, choosing travel agency software is the same anywhere: catalogue, bookings, quotes, a few reports. Then the local part shows up.
Two currencies in one sale. Instalments. Invoicing that depends on a government service which some days does not answer. And the agency that books today, operates next week and pays at the end of the month. None of that is unusual for inbound tourism in Argentina: it is a Tuesday. A management system built for another market solves half of it, and that half ends up in spreadsheets.
Two currencies in the same booking
The boat trip to Isla Victoria settles in dollars. The van and the guide are paid in pesos. The passenger pays however they can. That is not an edge case: it is an ordinary quote out of Bariloche.
A single-currency system lets you choose between two ways of losing. Load everything in pesos, and the margin on what you pay in dollars drifts with the exchange rate between the sale and the departure. Or load everything in dollars, and someone converts by hand, quote after quote, at whatever rate the day happens to bring.
What to ask for in the demo: each product with its own currency, a quote with one total per currency and no sum across them, and cash and balances kept apart. And where no rate has been entered by a person, the system should not invent one.
Instalments, bank transfers, and a passenger paying from Brazil
Here the payment method decides whether the sale closes, and it is never just one. The couple from Rosario asks about instalments. The family from São Paulo wants to pay from their bank's app. The German pulls out an international card without asking anything. And there is always someone who leaves a deposit and pays the rest in cash when they board the van.
Three things worth a close look:
- Somebody pays for the instalments. The financing surcharge is either in the price or out of your margin. The system has to show it at the moment of charging, not in a month-end report when nothing can be done about it.
- A transfer receipt is a file, not a payment. The system can review it and flag what does not add up, but the person who confirms works at the agency. Anything else is trusting a JPG.
- The payment belongs to the booking. A payment link sent outside the system leaves the booking unaware that it was paid, and that booking shows up unpaid on the day sheet.
Invoices, and the Saturday the tax service is down
Electronic invoicing depends on a government service that sometimes goes down. What cannot go down with it is your sale.
A system worth having issues the document with its own numbering, posts it to the sales ledger with the taxes broken out, and leaves the tax filing pending until the service returns. That is not a workaround: it is what lets you keep selling at ten on a Saturday morning, which is exactly when there is nobody to call.
Two details that look small and turn up in an audit. First, the rate depends on the product and on who is buying: the same excursion sold to a foreign visitor does not always carry what it carries for a resident. Second, the document has to stay attached to the booking that produced it; filed somewhere else, rebuilding an eight-month-old sale costs an afternoon.
Current accounts: here, credit is a way of selling
Selling to another agency means selling on credit. They book today, operate next week, pay at month end. In the meantime, that debt lives somewhere.
If it lives in a spreadsheet, the usual happens: it is updated at the end of the day, two people edit it at once, and at the moment of taking the booking nobody knows what that agency owes. Ask for the current account to be part of the booking system rather than an annex: every booking posted on its own, a credit limit able to stop the next one, and balances kept per currency.
What counts here and anywhere else
The four above are the Argentine ones. Three more have no nationality, and if they fail the rest hardly matters.
Capacity comes off when the sale happens, not when somebody updates the spreadsheet. Website, counter, a message, another agency: if the deduction arrives at the end of the day, overbooking is a matter of high season.
The quote has to be acceptable on its own. Sent as a PDF and answered with "go ahead" in a chat, it gets entered twice, and the second time somebody gets a date wrong.
The margin comes out of the system or it does not come out at all. With the supplier's cost loaded next to the product, every sale shows what it leaves. And when a product is missing that cost, the margin has to say it is unknown: a zero there reads as "I make nothing on this", which is a lie.
What about free software?
Almost every agency starts for free, and rightly so: a shared spreadsheet, a calendar, the group chat. That holds up to a fairly identifiable point, and the point always arrives in the same week of the year.
It arrives when two people sell the same departure on the same day. What is missing there is not a feature: it is one shared capacity across every channel. Same with the current account — a debt spreadsheet works with three buying agencies and becomes a problem with ten, because nobody knows the balance at the moment of saying yes.
Free tools are not the mistake. The mistake is finding their limit on a Saturday in January with two families at the door and one seat left.
Five tests for the demo
A demo is useful when it runs on your catalogue and on things that get shown rather than explained. These five separate the field quickly:
- Load an excursion you sell in dollars and another in pesos, and build a quote with both. Two totals, or one?
- Sell the same departure from two places at once. Does capacity drop in both, right then?
- Take a deposit by payment link and the balance by transfer. Does the booking show what was collected and what is missing, per currency?
- Set a credit limit on a buying agency and have it book past the limit. Does the booking stop on its own?
- Issue an invoice and ask what happens when the tax service does not answer. If the answer is "you wait", you will be doing that waiting on a Saturday.
When a system from abroad is enough
If the agency sells in one currency, charges through one method, does not sell to other agencies and invoices outside the system, international software can be plenty. Saying so does not help us, but it is true.
The point where it stops being enough is recognisable too, and it usually arrives all at once: the first sale in dollars, the first agency asking for credit, the first Brazilian who wants to pay from their bank. That is when the first parallel spreadsheet appears. And a parallel spreadsheet is a system nobody chose and everybody ends up using.