Finance and ERP inside the CRM

SigmaCRM includes a finance and ERP layer rather than integrating with one. It issues GST-compliant proforma and tax invoices across multiple billing entities with correct CGST/SGST/IGST treatment, place-of-supply logic and export handling; reconciles bank statements against open invoices; posts to a general ledger; and runs procurement, vendor bills and inventory. Because it sits on the same records as the pipeline, an invoice traces back to the deal, the scope and the delivery that produced it.

Invoicing that understands Indian tax, not just line items

Most CRMs generate a document called an invoice. That is not the same as issuing one a chartered accountant will accept. The invoicing engine here models the things that actually determine a tax invoice's validity:

• Place of supply and state codes, so the system applies CGST plus SGST intra-state and IGST inter-state rather than leaving the rep to choose.
• Export handling — zero-rated treatment with the export declaration, currency, and the country-specific billing profile applied automatically once the client country is set.
• Customer GSTIN validation, including the mod-36 check digit, so a mistyped GSTIN is caught at entry rather than at filing.
• Reverse charge, round-off and amount-in-words, which sound trivial until an invoice is rejected for missing them.
• Multiple billing entities, each with its own seller profile, numbering series, signatory list, stamp and bank details — snapshotted onto the invoice at issue, so reprinting an old invoice shows the entity as it was then.
• Purchase order capture, optional rather than mandatory, with PO number and date carried onto the document where the client requires it.

Proforma first, tax invoice on payment

Most compliance and audit firms issue a proforma, get paid, then raise the tax invoice. Systems that only understand one document type force a workaround — a duplicate record, a manual renumber, or a spreadsheet keeping track of which is which.

SigmaCRM models both. A document is issued as a proforma, and converts to a tax invoice on payment while keeping the same commercial identity, with the conversion recorded — who converted it and when. Numbering runs on a configurable series per entity and per document type, so an existing Tally series can be continued rather than restarted at 0001. Where e-invoicing applies, the IRN, acknowledgement number, acknowledgement date and signed QR are carried on the invoice record, and export to Tally is tracked with the resulting voucher number.

Reconciliation, ledger and the rest of the back office

Invoicing is only the visible end. The modules behind it are what remove the parallel spreadsheet:

• Bank reconciliation — import a statement and the matcher proposes an invoice for each credit, scoring on invoice number, exact amount, name similarity and recency, with dated and overpaid transactions penalised. You confirm or override; nothing auto-posts silently.
• General ledger and journal entries, so the accounting position is derived from the same records rather than re-entered.
• Accounts receivable and credit control, with configurable limits and exposure visible against the account that is asking for more work.
• Procurement — vendors, vendor invites, purchase orders, vendor bills and approvals, with procurement reporting and intelligence over the resulting spend.
• Inventory — items, stock lots and stock movements, for the firms that carry hardware or licences alongside services.
• Recurring invoices and credit notes, because retainers and adjustments are the normal case, not the exception.
• Tally integration, so the finance team keeps the system it files from while the commercial team works where the deal lives.

Why this matters more for a compliance firm than a generic CRM

A generic CRM assumes the invoice is somebody else's problem: it hands a closed-won deal to an accounting package and stops. For an audit or consulting business that hand-off is where the margin leaks — scope agreed in the proposal drifts from what was invoiced, milestones slip past their billing trigger, and nobody notices until quarter end.

Keeping scoping, delivery and invoicing on one record closes that gap. The invoice inherits the scope that was quoted, the payment matches back to it, and the receivable sits against the same account the delivery team is working for. That is the argument for finance inside the CRM rather than beside it.

Does SigmaCRM replace Tally?

No, and it is not trying to. Most Indian finance teams file from Tally and will continue to. SigmaCRM issues and tracks the commercial documents where the deal lives, then exports to Tally with the voucher number recorded against the invoice. If you would rather run accounting natively, SigmaFin is the product for that.

Does it handle GST correctly for inter-state and export invoices?

Yes. Place of supply and state codes drive the tax treatment — CGST plus SGST intra-state, IGST inter-state — and setting a client country outside India switches the invoice to zero-rated export treatment with the declaration and the country's currency applied. Customer GSTINs are validated including the check digit at entry.

Can we keep our existing invoice numbering?

Yes. Numbering is configurable per billing entity and per document type, including the starting number, so an existing series can be continued rather than restarted. That matters when your accountant expects the sequence to be unbroken across the financial year.

How does the proforma to tax invoice conversion work?

A document is issued as a proforma and converts on payment, retaining its commercial identity, with the conversion recorded against the record — who did it and when. This mirrors how most compliance firms actually bill: proforma out, payment in, tax invoice issued.

Does bank reconciliation post automatically?

No, by design. The matcher proposes a likely invoice for each credit and scores its confidence on invoice number, exact amount, name similarity and recency, penalising pre-dated and overpaid transactions. A human confirms. Auto-posting a wrong match is far more expensive to unwind than confirming a right one.

Do you support multiple legal entities?

Yes. Each billing entity carries its own seller profile, numbering, signatories, stamp and bank details, and those are snapshotted onto the invoice at the moment of issue — so reprinting a two-year-old invoice shows the entity as it was then, not as it is now.