Automate Ecommerce Orders Into Tally as GST-Correct Vouchers

Here is the question we get from multichannel sellers almost every week, phrased almost identically each time: "I sell on Amazon, Flipkart and Meesho, plus my own Shopify store. Every order eventually has to become a GST voucher in TallyPrime. Right now my accountant re-types them. How do I make orders land in Tally automatically, and correctly?"

It is a fair question with a real answer, but the honest version has more edge cases than the marketing version. Let us walk through how to automate ecommerce orders into Tally properly: the workflow, the GST details that trip people up, and the one decision, consolidated versus per-order invoicing, that shapes the whole build.

The workflow, described as a diagram in words

Ignore the tools for a second and picture the flow. It has four stages, and every reliable Tally automation follows this shape:

Source order → normalise into a common format → map to a GST-correct voucher → post into Tally and confirm.

Stage one, source, is where orders come from: your Shopify store, plus each marketplace. Shopify sends order data cleanly. Marketplaces are messier, so you pull sales through their reports or connectors, for example the Amazon and Flipkart seller feeds, each with its own fields and quirks.

Stage two, normalise, is the part people skip and regret. Amazon calls a field one thing, Flipkart another, Shopify a third. Before anything touches Tally you translate every source into one internal shape: order id, date, buyer, ship-to state, line items with HSN, taxable value, tax rate, tax amount, and invoice number. Get this layer right and the rest is easy.

Stage three, map to a voucher, is where the accounting logic lives: which ledger the sale hits, how CGST/SGST or IGST is split, which HSN each item carries, and what the party details are. Stage four, post and confirm, sends the voucher into Tally, typically through Tally's XML/ODBC gateway, and reads back a success or an error so nothing is silently dropped.

The GST edge cases that break naive setups

A demo that posts one clean Shopify order into Tally looks great. Production breaks on the details. These are the ones to plan for.

Place of supply and the CGST/SGST vs IGST split

Whether a sale is intra-state (CGST + SGST) or inter-state (IGST) depends on your GSTIN state versus the ship-to state. Marketplaces ship pan-India, so the same product will legitimately post different tax structures on different orders. Your mapping layer has to compute this per order from the delivery state, not hard-code one split.

HSN codes per line item

GST invoices need the correct HSN code per product, and the rate follows the HSN. If your catalogue does not carry clean HSN mappings, the automation has nothing correct to post. Half of a good Tally project is really just cleaning up the product-to-HSN master once, so every future order inherits it.

B2B vs B2C and GSTIN capture

A B2B buyer who gives a GSTIN needs a tax invoice with their GSTIN so they can claim input credit; a B2C order does not. Marketplace exports handle this inconsistently, so your flow needs a rule: if a buyer GSTIN is present and valid, create the party ledger and attach it; otherwise post as B2C.

Returns, cancellations and settlement fees

Orders get cancelled and returned, so you need credit notes, not just invoices. And marketplaces deduct commission, shipping and fees before settling, which your accountant will want reflected. Decide up front whether those deductions are booked in this automation or reconciled separately, because it changes the design. Returns are especially easy to forget in a first version, and forgetting them means your Tally sales figure is permanently inflated by every product that came back. Build the credit-note path in from the start, even if returns are rare, because retrofitting it after months of one-directional posting means a painful clean-up of the books.

Consolidated vs per-order invoicing: pick before you build

This is the fork in the road. There are two valid patterns and they suit different businesses.

• Per-order vouchers: every single order becomes its own sales voucher in Tally. This gives you order-level detail and matches how your own website invoices customers. It is the right default for D2C brands and lower volumes. The cost is voucher volume, thousands of entries a month at scale.
• Consolidated vouchers: marketplace sales are summarised, often one voucher per marketplace per day or per settlement, matching the settlement report. This keeps Tally clean and reconciles neatly against the money that actually hits your bank. Many CAs prefer this for Amazon and Flipkart volume.

A common, sensible hybrid: per-order for your own Shopify store where you issue the customer invoice, and consolidated for marketplaces where the marketplace already issued the tax invoice and you mainly need the numbers to reconcile. Whatever you choose, decide it with your accountant first, because retrofitting the other pattern later is a rebuild.

A worked example: one product, three channels, one day

Picture a single SKU, a cotton kurta with HSN 6109, sold on a Tuesday. On your Shopify store a Delhi customer buys it; your GSTIN is in Delhi, so the voucher posts CGST + SGST. On Amazon a Bengaluru buyer orders the same kurta; ship-to is Karnataka, so that voucher posts IGST. On Flipkart a small retailer buys ten pieces and enters a GSTIN; that becomes a B2B tax invoice with the buyer's party ledger attached so they can claim credit. On Meesho two units sell to consumers with no GSTIN, booked B2C.

Same product, same day, four legitimately different vouchers. A person doing this by hand has to remember the place-of-supply rule, the HSN, the B2B check, and the correct ledger for every single line. An automation applies those rules identically every time, which is exactly why it is both faster and more accurate than manual entry. The rules never get tired at 9pm.

Reconciling against the money that actually arrives

Booking the sale is only half the job. Marketplaces do not pay you the invoice value; they pay the settlement value, order total minus commission, shipping, and various fees, days or weeks later, in batches. If your Tally only ever sees gross invoices, your books will never match your bank. A complete automation therefore also ingests the settlement reports, books the fees and commissions to the right expense ledgers, and lets you tie the payout to the orders it covers. Decide early whether this lives inside the same automation or runs as a separate reconciliation step; either works, but it should be a conscious choice, not an afterthought discovered at audit time.

Build vs buy, honestly

There are ready connectors that push Shopify or a single marketplace into Tally, and if you sell on one channel with a simple catalogue, use one. They are cheaper than a custom build and good enough.

The build case appears exactly in the situation the question described: three or four sources, mixed B2B and B2C, HSN rules, place-of-supply logic, and a specific consolidated-vs-per-order preference your accountant insists on. Generic connectors either do not cover all your channels or force their invoicing model onto you. At that point a custom automation that you own tends to cost less over a year than three overlapping subscriptions plus the manual fixing they still leave behind.

Real-time or batch? A timing decision

You do not have to post every order the instant it happens. Two timing models both work, and the right one depends on your accountant's rhythm. Real-time posting means each order becomes a voucher as it is confirmed, so Tally is always current, useful if you watch cash and stock live. Batch posting runs on a schedule, say once nightly, collecting the day's orders and posting them together, which is calmer, easier to review, and pairs naturally with the consolidated-invoice pattern. Marketplaces often suit batch because their own reports are periodic anyway, while your own store can go real-time. Many setups do exactly that: live for Shopify, nightly batch for Amazon and Flipkart. Decide it deliberately, because it affects how errors are caught and reviewed.

What a good implementation feels like

When it is done right, nobody thinks about it. Orders flow in through the day, vouchers appear in Tally with the correct tax split and HSN, returns generate credit notes, and if a marketplace report format changes, you get an alert instead of a silent gap. Your accountant opens Tally at month-end and the numbers are already there and already reconcile.

That is the goal: not a flashy dashboard, but a quiet pipeline your books can trust. If you want that mapped for your exact channel mix and GST setup, start with our automate orders into Tally service. We begin with a free audit of your sources and catalogue, agree the invoicing model with you, and only then build.