Tally on RDP Servers: E-commerce Integration Guide
A large share of Indian firms do not run TallyPrime on the accountant's own laptop — it lives on a shared Windows server reached over RDP, where the CA firm, the client and the data-entry team all log in to the same installation. That setup changes how marketplace integration has to work: the tool posting vouchers must reach a Tally instance that is running on a machine nobody physically sits at. Here is how to wire it up correctly, and the security mistakes that make hosted Tally dangerous.
Why Tally ends up on RDP servers
TallyPrime is Windows software, and its data lives in a folder on the machine running it. Put that machine in a data centre and every stakeholder gets the same books from anywhere, licences are pooled, and backups happen in one place. CA firms in particular standardise on this: one server, dozens of client companies, staff logging in over RDP. The trade-off is that any integration — including marketplace import — must run where Tally runs, because Tally's HTTP interface listens locally on that server.
Licensing and sessions add a wrinkle worth planning around. Tally runs per Windows session, and on busy servers several users may have different companies open in their own sessions at once. Decide which session owns integrations — usually a dedicated account whose session stays logged in with the right company loaded during import windows — and document it, so a reboot or a logged-off session does not silently take the interface down mid-batch. Monitoring can be as simple as the import tool alerting when localhost:9000 stops answering. Disk hygiene matters too: keep company data and backups on separate volumes so a full disk never corrupts both at once.
The golden rule: the connector runs beside Tally
TallyPrime's local HTTP interface (enabled via F1 > Settings > Connectivity, acting as Both, default port 9000) is designed for same-machine or LAN use. On an RDP server the correct pattern is:
- Install the integration tool on the RDP server itself, in the same session context where TallyPrime runs.
- Point it at localhost:9000 — traffic never leaves the machine.
- Let the tool reach the outside world only through outbound HTTPS, to fetch data or updates.
This is exactly how the TallySutra Gateway is built: it installs on the server next to Tally (beta installers exist for Windows, macOS and Linux; on a typical RDP box you want the Windows one, and being unsigned beta builds, SmartScreen will ask you to confirm), makes outbound-only connections to fetch CA-approved batches, and posts them to Tally on localhost. Nothing ever connects inward. Setup steps live on the download page.
The lines you must not cross
| Tempting shortcut | Why it is dangerous | Do instead |
|---|---|---|
| Port-forward 9000 to the internet | Anyone who finds it can read ledgers and post vouchers — the interface has no real authentication | Keep 9000 bound to localhost; use an outbound-only connector |
| Open 9000 to the whole office LAN | Every laptop and phone on the network can write to your books | Firewall to specific internal IPs if LAN access is truly needed |
| Run imports while others key vouchers | Interleaved entries make verification and numbering messy | Schedule imports in a quiet window; verify counts after |
| Share one Windows login for everyone | No audit trail of who imported what | Separate RDP users; keep the Gateway under a known account |
Multi-company servers need open-company checks
The subtle RDP hazard is the wrong company. A CA firm's server has dozens of companies, and Tally's HTTP interface posts into whichever one is open. An import meant for one client landing in another client's books is a nightmare scenario. Two defences: make it procedure that the operator confirms the open company before any import, and use tooling that checks. The TallySutra Gateway validates the open company against the batch before posting and refuses to proceed on a mismatch — it also refuses batches that have not been CA-approved. The broader design is documented on the security page.
A deployment checklist
- TallyPrime set to act as Both, port 9000, confirmed reachable from localhost only.
- Windows Firewall: no inbound rule for 9000 from outside the machine.
- Integration tool installed on the server, running outbound-only.
- Import window agreed with the data-entry team.
- Backup taken before the first bulk import — see the backup guide.
Get these five right and hosted Tally is a perfectly good home for automated marketplace accounting.
Frequently asked questions
Can a tool on my laptop post directly to Tally running on our RDP server?
Only if the server's port 9000 were opened to the network, which you should not do. The safe pattern is to run the integration tool on the server itself, talking to localhost, with only outbound internet access.
How do I stop an import landing in the wrong company on a multi-company server?
Tally posts into whichever company is open, so make confirming the open company a hard step in your procedure, and prefer tooling like the TallySutra Gateway that validates the open company against the batch and refuses on mismatch.
Does the TallySutra Gateway need any inbound firewall rule on the server?
No. The Gateway makes outbound HTTPS connections to fetch approved batches and posts to Tally on localhost. No inbound port needs to be opened, which is the point of the design.
TallySutra turns Amazon, Flipkart and Meesho reports into reconciled, reviewed TallyPrime vouchers — duplicate-safe, with every rupee traceable to its source row.
Book a 30-minute demo