The questions we get before every demo.

It is built for Indian textile and ethnic-wear retail, and that is where it fits best - saree and silk houses, bridal and occasion wear, and textile wholesale. The concepts it models (per-piece identity, selections, jobwork, value addition, floor-wise counters) come from that trade. It is not a general-purpose ERP with a textile theme, and we will say so if your business is not one of these.

One system. Channels and warehouses scope data per branch, so branch staff see only their branch, while multi-daybook and branch reports consolidate for the owner. Inter-branch transfers move stock with gatepass documentation, and each branch can carry its own GSTIN with correct place-of-supply handling.

No. ambar 27 handles jobwork and value addition on finished pieces - embroidery, fall and pico, tassels, zari repair - with per-worker outstanding tracking and cost posting onto the item. It is not a production-planning or bill-of-materials system for a mill.

You can, but much of the value is in floor, counter, approval and multi-user control. A small single-counter shop will be paying for depth it will not use, and we would rather tell you that than sell it.

A single showroom is typically around seven weeks: a week of discovery, two to three weeks of masters and migration, two weeks of parallel running, then cutover and training. Multi-branch groups usually pilot one branch through a full season before rolling out the rest.

Your item and design list, category structure, customer and supplier masters with opening balances, ledger balances, and a physically verified opening stock. The condition of that data is the single biggest factor in how long implementation takes - clean data migrates in days, fifteen years of inconsistent naming takes weeks.

No. You bill on ambar 27 in parallel with your current system for an agreed period, with daily tie-outs on sales, stock and cash. We do not declare go-live until both agree for a full week, so cutover is a formality rather than a leap.

That is the normal starting position, and cleaning it is part of implementation - merge category and merge customer tools exist precisely because years of counter entry create duplicates. What we need is someone on your side who can make the calls about what merges into what.

For operations, yes - sales, purchase, inventory, cash, banking and receivables all live in ambar 27. Most clients keep Tally as the statutory book and push mapped vouchers to it, so their CA’s workflow is unchanged and nothing is re-keyed.

The IRN is generated as the invoice is raised at the counter, using your own GSP credentials configured per GSTIN, and the signed QR prints on the invoice. If the portal is unavailable the invoice is still raised and the IRN is queued as a visible worklist that retries - billing never stops because a government API is down.

It produces the returns - GSTR-1 from your live invoice data, a GSTR-3B summary reconciled to it, and GSTR-2A / 2B reconciliation against your purchase register so you see supplier mismatches while there is still time to chase them. Filing itself stays with you or your CA.

In both directions. TDS sections carry rates and thresholds, a threshold tracker flags parties crossing them, and the TDS planner applies the deduction before a payment is released and generates the voucher. TDS receivable is tracked separately with payer statements and utilisation.

Billing stops until the connection is back, because the system is hosted rather than sitting in your building. This is the one dependency worth planning around: we will tell you to keep a second connection from a different provider, which is far cheaper than a counter standing idle on a festival evening. Nothing is lost when the line returns - the system is exactly as you left it.

Usually yes. Barcode label design, reprint and direct printing through QZ Tray are built in, and thermal templates cover counter printing. Compatibility with your specific hardware is confirmed during discovery, not assumed.

We do. We choose the provider and region, size the instance against your own peak-week figures, and keep it patched, monitored and backed up. You never provision a server, renew a certificate or get called at night about one - and there is nothing for your team to administer.

It is built for full showroom floors with every counter billing at once. We size the instance at install against your own festival-week figures rather than an average day, because that week is the load that actually matters.

We do, role by role - counter staff learn billing and selections, cashiers learn settlement and close-day, accounts learn planners, returns and reconciliation. Printed SOPs are left behind for each role, so a new hire in six months has something to read.

Application issues, integration failures, configuration changes and guidance, from a named team that knows your specific setup. The server is included too, since we run it. New development is scoped separately.

Yes. The standard library covers most of what a textile business asks for, and anything specific to yours is built during implementation or as a support engagement. Custom reports travel with your instance through upgrades.

In a MySQL database used by your business alone, never pooled with another client’s, on infrastructure we provision and manage. Nothing you record is visible to another customer of ours. Backups are taken daily and kept for seven days so a mistake can be rolled back, and they are held by us for recovery rather than distributed.