Google Business Profile software: GST-compliant billing explained

If you buy Google Business Profile management software as an Indian business, the invoice matters almost as much as the price. A tax invoice that carries the right GSTIN, the right tax split, and a valid sequential number is what lets your finance team claim input tax credit; one that does not is an expense you effectively pay full freight on. This post explains what GST-compliant billing actually requires for a software subscription, why the split between CGST/SGST and IGST is decided by geography rather than by preference, and how PlaceOptimizer's invoice engine implements it.

Nothing here is tax advice. It is an engineering description of a working invoice generator, written so you can check our claims against the statute yourself. Your chartered accountant is the authority on your own filings.

What makes an invoice GST-compliant?

A GST-compliant tax invoice is a document issued by a registered supplier that carries a specified set of fields, most importantly the supplier's GSTIN, a unique consecutive invoice number within the financial year, the date of issue, the recipient's details and GSTIN where registered, the HSN or SAC code of what was supplied, the taxable value, the rate and amount of tax split into its components, and the place of supply. Those requirements sit in the CGST Rules (the Central Goods and Services Tax Rules published on the CBIC tax information portal, accessed August 2026), and the government's own e-invoicing system encodes the same field set (the GST e-invoice system operated by the Goods and Services Tax Network, accessed August 2026).

The practical consequence for software buyers is blunt. A foreign vendor billing you in dollars from a non-resident entity frequently issues a commercial invoice rather than a GST tax invoice, and a commercial invoice does not carry the fields your credit claim depends on. That is not a knock on the vendor; it is a structural fact about where the supplier is registered, and it is worth establishing before you sign rather than at quarter close.

CGST plus SGST, or IGST: the place-of-supply rule

The tax on a supply splits one of two ways, and the split is determined by comparing the supplier's state with the place of supply, not by anything either party chooses. When the two are the same state, the tax is levied as CGST plus SGST, each at half the total rate. When they differ, the whole amount is levied as IGST at the full rate.

For an 18% rate on a supply from a Maharashtra-registered supplier, that means a Pune customer sees CGST 9% and SGST 9% on two separate lines, while a Bengaluru customer sees a single IGST 18% line. The total tax is identical either way. Only the composition of the line items changes, and it changes because those are constitutionally different levies going to different treasuries, not because one is a discount.

Our engine implements exactly this comparison: it takes the supplier's state code and the customer's place-of-supply state code, and branches on whether they are equal. There is no configurability, no override, and no user-facing toggle, because the correct behaviour is fully determined by the two state codes.

Why the arithmetic runs in integer paise

This is the part that looks like a detail and is not. Amounts collected through a payment gateway are GST-inclusive: the customer is charged one gross figure, and the taxable base plus the tax has to reconcile back to that exact figure. If the arithmetic runs in floating point, it will not, and a mismatch of a single paisa between an invoice total and a bank settlement is a reconciliation problem that costs someone an afternoon every month.

Our invoice engine stores and computes every amount as an integer number of paise, never as a rupee float. The taxable base is back-computed from the gross by dividing out the rate, the tax is then defined as the exact remainder of gross minus taxable, and for the intra-state case the odd paisa is assigned deterministically to SGST so that CGST plus SGST equals the tax component to the last paisa.

That gives a reconciliation invariant we assert in tests rather than assume: taxable value plus CGST plus SGST plus IGST equals the gross amount charged, exactly, for both the intra-state and the inter-state branch. An invoice that fails that identity is a bug, not a rounding nuance.

The invoice also renders the total in words, in the Indian numbering system, so an amount reads as "Indian Rupee One Lakh Twenty-Three Thousand Four Hundred Fifty Only" with lakh and crore boundaries rather than the Western thousand-million grouping. Amounts on the invoice are grouped the same way, so ₹1,23,450.00 appears with the two-digit grouping an Indian reader expects.

SAC 998313, and why the code on the line matters

Services carry a Service Accounting Code on the invoice line, the services counterpart to the HSN code used for goods. PlaceOptimizer's subscription lines carry SAC 998313, which sits in the information-technology consulting and support services family under the GST services classification (the GST rate and classification pages published by CBIC, accessed August 2026).

The code matters for two reasons that are easy to underrate. It is the field your accounting system uses to classify the expense and to validate the rate applied, so a missing or wrong code makes an otherwise valid invoice awkward to book. And because it is printed on the document, it is something you can check on a sample invoice during evaluation rather than taking on trust from a feature grid.

Invoice numbering: one continuous series per financial year

GST requires the invoice number to be unique and consecutive within a financial year, and the Indian financial year runs from 1 April to 31 March rather than following the calendar. That second fact quietly breaks a lot of billing code written against a January-to-December assumption.

Our numbering is PO/2026-27/000001: a fixed prefix, the financial-year label, and a six-digit zero-padded sequence. The financial-year label is derived from the issue date with the April boundary applied, so an invoice issued on 1 April 2026 belongs to FY 2026-27, and one issued on 31 March 2026 belongs to FY 2025-26. An invoice issued in February 2026 belongs to the year that began in April 2025, which is the case a naive implementation gets wrong.

Zero-padding to six digits is not cosmetic either. It keeps the series sorting correctly as text in a spreadsheet, which is where these numbers spend most of their working life.

What to ask any vendor before you buy

Four questions, all answerable from a sample invoice, all worth asking of us as much as of anyone else.

1. Will you issue a GST tax invoice, from which registered entity? Ask for the supplier GSTIN and confirm the entity is registered in India. A supplier who cannot answer this is billing you commercially, whatever the document is titled.
2. Show me a sample invoice for my state. Check that the tax split matches the place-of-supply rule for your state relative to theirs. If a vendor in another state shows you CGST and SGST, something is wrong with either the invoice or your understanding of where they are registered.
3. What SAC code do you use, and is it on the line? A blank code column on a sample invoice is a real finding.
4. How is the invoice number formed, and does it reset with the financial year? You are checking that they know the year runs April to March.

The honest status of our billing

PlaceOptimizer's GST invoice engine is built and tested: the tax computation, the place-of-supply branch, the FY-sequential numbering, the rendered invoice document, and the delivery email all exist in the codebase, with the reconciliation identity asserted in unit tests. Payments run through Razorpay as the rail, and PlaceOptimizer generates the tax invoice itself rather than relying on the gateway's receipt.

What that does not mean is that we have a long billing history to point to. The platform is in public beta and onboarding its first design partners, so the correct way to read the section above is "here is how the engine works, verifiable on a sample invoice" rather than "here is a system proven across thousands of customer invoices". We publish our per-location rupee pricing on the pricing page with GST stated separately, and the cost calculator will multiply it out against your location count alongside the vendors who publish comparable numbers.

Frequently asked questions

Can I claim input tax credit on GBP management software?

If you are GST-registered, the supply is used in the course of your business, and you hold a valid tax invoice from a registered supplier, the ordinary conditions for input tax credit are the ones that apply — and the invoice is the piece most likely to be missing when a vendor bills from outside India. This is exactly the question to put to your chartered accountant with a sample invoice in hand rather than to a software vendor, including us.

Why does my invoice show IGST when a colleague's shows CGST and SGST?

Because the two of you are in different states relative to the supplier. Our supplier registration is in one state; when your place of supply is that same state the tax is levied as CGST plus SGST, and when it is a different state the whole amount is levied as IGST. The total tax is the same in both cases, so the difference changes which lines appear and which treasuries the components go to, not what you pay.

What is SAC 998313 on the invoice line?

It is the Service Accounting Code that classifies the supply, sitting in the information-technology consulting and support services family under the GST services classification (the GST rate and classification pages published by CBIC, accessed August 2026). It is printed on the line item so your accounting system can classify the expense and validate the rate applied.

Does the invoice number restart every year?

The sequence is scoped to the Indian financial year, which runs 1 April to 31 March, so the counter starts again at 000001 under a new year label each April. An invoice issued in February carries the label of the year that began the previous April, which is the boundary case most calendar-year implementations get wrong.