The GoRoute connector is a small Windows program that runs beside TallyPrime. It reads the sales vouchers you already post, converts them to Peppol UBL, validates them against the destination country's rules, delivers them and files the tax report. You keep posting vouchers exactly as you do today.
The recording below runs thirteen minutes and covers the whole path in fifteen chapters, from switching on Tally's gateway to reading the status back on the dashboard. The same walkthrough is written out further down the page, chapter by chapter, if you would rather read it than watch it.
Below is the recording written out, chapter by chapter and in its own order, so the page answers what the connector does without anyone pressing play. Where a detail comes from the TallyPrime connector page or the Oman TallyPrime guide rather than from the video, it says so.
TallyPrime handles Oman VAT accounting perfectly well. What it has no native capability for is the network side: it cannot produce PINT OM UBL, generate a tax data document, sign an invoice, or transmit over AS4. Those four things are what Fawtara actually requires, and none of them is an accounting function.
So the gap is not in Tally. It is between the voucher Tally already records and a legally valid e-invoice, and that gap is what a certified Peppol Access Point fills. The recording opens on exactly this point, because it decides the shape of everything after it: nothing about Tally has to change, and something has to sit next to it.
It is a small Windows application that runs on the machine that reaches Tally, starting automatically when you log on and working in the background. It reads posted sales vouchers over Tally's own XML gateway, converts each one to Peppol BIS 3.0 UBL with parties, tax breakdown, line items and totals mapped across, and hands the result to GoRoute. Nothing is re-keyed: the voucher you already posted becomes the invoice that is sent.
Four steps, once, and about ten minutes. First, switch on Tally's gateway: in TallyPrime, F1 Help → Settings → Connectivity, set TallyPrime acts as: Both, port 9000. TallyPrime accepts no connections at all until this is on, which is why an installation that looks perfect can sit there sending nothing.
Second, run the installer — it installs under your own Windows profile, with no elevation, no IT ticket and no reboot. Third, enter three details: your API key, your Tally company name exactly as Tally displays it, and which invoice-number prefixes to send. Fourth, post a voucher. The connector picks it up within seconds.
It ties the installation to the machine it is running on. The API key is written to a configuration file at install time, and on first run the connector replaces the plaintext with a copy encrypted using Windows DPAPI, which is bound to your Windows user profile. That is also why the connector installs per-user and runs as you rather than as a Windows service: a service running under the SYSTEM account could not decrypt it. A key that never sits readable on disk is the point of the exercise.
Exactly as you do now. You post a sales voucher; there is no new screen, no second data entry and no GoRoute field to remember. The only configuration that touches your daily work is the prefix list you set at install time, which decides what is picked up. Quotes, proformas and internal vouchers stay where they are, however they happen to be numbered — so a business can send its customer invoices without sending its internal paperwork with them.
The connector polls Tally's XML gateway for new posted vouchers every five seconds, with a five-minute reconciliation cycle behind it to catch anything the poll missed. Each voucher becomes Peppol BIS 3.0 UBL. For Oman that includes three-decimal baisa amounts on line values, because the rial has a thousand baisa while document totals stay at two decimals — both rules apply at once, and getting one of them wrong fails validation on every invoice.
Against the destination's own Schematron rules, before anything is transmitted. For Oman that is PINT OM v1.0.1. The order matters more than the mechanism: a document stopped on your own machine costs minutes, while one rejected on the network costs days and involves your customer.
A failed invoice is held rather than sent, and the connector's status window names which rule failed and on which voucher. You fix the voucher in Tally and the next poll picks up the corrected version — there is nothing to resubmit by hand. The first field to check when everything fails at once is the seller VAT identification number: an Omani VATIN is the letters OM followed by exactly ten digits, and it becomes your Peppol participant identifier as 0248:OM followed by that number.
The connector sends the data to GoRoute over HTTPS and GoRoute takes it from there. We look your customer up in the network directory and hand the document to their provider over AS4 as a certified Access Point — no portal, no email attachment. In Oman the tax data document goes to the Tax Authority as part of the same flow, so there is nothing to assemble and nothing to file separately.
The status of the invoice, and for the document types that require one, the QR code. This is the chapter that answers the question a Tally user actually has — not “did it send” but “what does the business have afterwards that proves it”. The response is what turns a submission into a record.
In the GoRoute dashboard, which holds the audit trail: what went out, what each document was validated against, and what the receiving side acknowledged. An invoice raised in Tally and one raised in the portal end up in the same register carrying the same kind of record, because the connector is a route in rather than a separate system. You do not need to keep a browser tab open for any of it to work.
Vouchers queue locally and are retried rather than lost, which is the chapter that matters most to a business on an unreliable line. The five-minute reconciliation cycle is the backstop: anything the five-second poll did not manage is picked up on the next pass. The design assumption is that the network will fail sometimes and that a missed invoice must not be the way you find out.
Only the invoices you chose to send. The connector reads posted sales vouchers matching your configured prefixes and sends those. Your ledgers, masters, stock and every other voucher type stay on the machine — the connector never reads them. Combined with the DPAPI-encrypted key described above, that is the whole security position: a per-user install, a key bound to that profile, and a deliberately narrow read.
Credit notes and debit notes map to the corresponding PINT OM document types, including invoice type code 383 for debit notes, and both are in scope for Fawtara reporting alongside the original invoice. On countries, the destination decides which rule set an invoice is validated against and none of it is configured per country: Oman Fawtara, Saudi ZATCA, the UAE programme, the EU under EN 16931 and Peppol BIS Billing 3.0, Singapore and Malaysia, and Australia and New Zealand. One connector and one account covers all of them. The connector is built and tested against TallyPrime; Tally.ERP 9 exposes the same gateway and works in principle, but we do not certify it — talk to us first if that is what you run.
No. You keep creating sales vouchers exactly as you do today. The connector runs alongside Tally, reads posted vouchers over Tally's own XML gateway, and does the conversion and delivery in the background. There is no new screen to learn and no data re-entry.
In TallyPrime press F1 for Help, choose Settings, then Connectivity, and set “TallyPrime acts as” to Both. Leave the port at 9000. TallyPrime does not listen for connections until you do this, so the connector will install successfully but find nothing to send until the setting is on.
No. TallyPrime handles Oman VAT accounting, but it has no native Peppol capability — it cannot produce PINT OM UBL, generate a tax data document, sign invoices, or transmit over AS4. Those functions come from a certified Peppol Access Point that TallyPrime connects to.
Only the invoices you choose to send. The connector reads posted sales vouchers matching the invoice-number prefixes you configure at install time and sends those. Your ledgers, masters, stock and every other voucher type stay on your machine — the connector never reads them.
An Omani VATIN is the letters OM followed by exactly ten digits. This becomes your Peppol participant identifier as 0248:OM followed by that number. A malformed seller VATIN fails validation on every invoice, so it is the first field to verify.
It is held, not sent, and the connector's status window shows which rule failed and on which voucher. Validation runs before transmission on purpose: a rejected invoice on the network is far more expensive to unpick than one stopped at your own machine. Fix the voucher in Tally and the next poll picks up the corrected version.
This recording shows the same platform you would be buying, doing the thing you would be buying it for — on a Peppol-certified access point.
Press Esc, click outside, or use the ✕ to close and stop playback.
