Shopify GST accounting features, shown by workflow.

Resolve the native B2B Company name, then shipping-address Company, with a configurable note-attribute or metafield fallback.

Exclude B2B orders you invoice yourself. Disabling B2B party creation instead gives B2C treatment; it is not an existing-parties-only mode.

Shopify's checkout has no native GSTIN field -- Ledgeree reads it from a checkout note attribute, an order or company metafield, or Shopify's native B2B/Wholesale company (Shopify Plus), configurable per shop.

Customer names vary and typo across orders ("Acme Pvt Ltd" vs "ACME Private Limited") -- the one reliable identifier is the GSTIN, so party-ledger lookup is always keyed on it, checked before ever creating a new ledger.

The first order from a new B2B customer creates their dedicated ledger (name + GSTIN + state) on the fly -- idempotent, so a hundred repeat orders from the same customer never create a hundred ledgers.

B2B orders are excluded from the standard state-day gateway/website aggregate entirely and post against the customer's own ledger, preserving the GSTIN-linked party treatment needed for review.

Unlike the B2C daily aggregate, every B2B fulfillment gets its own voucher -- so a tax-credit invoice always maps to exactly one real shipment, never a blended multi-order total.

B2B sales and returns post to dedicated ledgers, kept separate from ordinary retail Sales/Sales Return -- your B2C and B2B revenue never mix in one account.

If auto-ledger-creation is switched off, a captured GSTIN is simply ignored and the order falls back to plain B2C -- a deliberate escape hatch, not a silent failure.

Any order shipping outside India is treated as an export -- no manual flagging per order.

Every line item is posted at 0% GST regardless of its normal domestic rate -- but only once a valid LUT (Letter of Undertaking) number is configured; without one, the export order is blocked (not silently posted at the wrong rate).

A LUT is filed per financial year and goes stale every April 1st. Ledgeree records which FY your LUT covers, blocks an export order whose FY doesn't match, and nudges you every January-March to file the next year's LUT before the current one expires.

Like B2B, export orders are never folded into a daily aggregate -- a Shipping Bill (customs) is issued per physical shipment, so one voucher always maps to exactly one shipping bill, never several blended together.

Kept out of your domestic Sales accounts entirely, same principle as B2B.

A Shipping Bill doesn't exist until customs actually clears the shipment, days after the order syncs -- so Ledgeree lets you record the Shipping Bill number, date, and port code against the already-posted voucher once you have them, for your Rule 46 compliance records.

When a customer is charged in a foreign currency, that currency and total are recorded alongside the INR figures your books actually need (already correctly converted by Shopify's own payment processing) -- so you have both figures on file without a manual note.

Don't want export orders synced at all? A single toggle excludes them from sync entirely, with no blocking errors generated for orders you've chosen to handle yourself.

Handle partial goods returns, monetary-only refunds, repeated events and partial shipping refunds. Later credits respect remaining booked value; monetary-only refunds carry no inventory quantities.

Before eligible same-day posting, fully returned value can be excluded and partial returns retain the remaining sale. Already-posted work follows the applicable correction path.

Posted as a separate return-date aggregate -- gross sales and returns stay visible on separate lines instead of being silently netted against the original entry.

Later goods returns use the configured return accounting so gross sales and returns can be reviewed separately; assess both to understand net revenue.

For a split-payment order, Ledgeree uses the refund's successful Shopify transactions to reverse the clearing ledgers that actually funded the refund, including refunds spread across multiple fulfillments.

When Shopify marks a refund as no-restock, Ledgeree can route the value through the configured goodwill write-off treatment instead of pretending inventory came back. Detailed Zoho behaviour should be verified in your own organisation during setup.

A fulfillment cancellation triggers a pull-based order resync with an idempotency guard, so the changed shipment state is re-evaluated without creating duplicate accounting work.

Choose a shop-timezone daily start, attempts and retry interval. Correct errors and Resume, re-sync eligible recent activity, or backfill up to 60 days subject to volume and pricing checks. Full push is a separate opt-in after clearing corresponding ERP entries.

Configure test and live companies. Test mode posts actual vouchers to the designated test company so you can review accounting before switching to live.

Ledgeree’s cloud service communicates with the local relay, which connects to Tally on your network. You do not need to expose Tally’s port publicly.

Get an early warning at 80% and 20% headroom above your shipment allowance. Posting pauses above 120% until you choose a higher-capacity plan that covers usage. Capture continues for the first 60 days of that pause; Pricing explains delayed-upgrade charges and the reminder timeline.

A failed push retries automatically; if it keeps failing, sync pauses and the real ERP error message is logged -- not just "something went wrong."

Compare expected Shopify accounting with recorded Tally or Zoho figures, including supported shipping, discount, tax, goodwill, gift-card and settlement-ledger checks. Itemized shops can also compare stock quantities. Bank deposits and payout matching remain separate.

See paid orders still unfulfilled beyond your configured window and failed Shopify refund transactions in one place. Ledgeree surfaces the exception; it does not guess the corrective action or silently create a journal entry.

Ledger and Stock Item choices can be checked against synced Tally or Zoho master data, reducing spelling drift and preventing a free-text mapping from quietly pointing at the wrong account.

Tally has no cloud API of its own -- the Ledgeree Agent bridges your local Tally installation to Ledgeree's sync engine.

Zoho's own REST API is called directly -- GST itself is computed by Zoho from each line's tax percentage, so the same canonical order model drives both adapters without duplicating tax logic.

Both integrations use the shared accounting model. Tally vouchers and Zoho invoices, credit notes, payments and inventory mechanisms represent that model differently.