Reporting tags

You sell across four states and your accountant can tell you what you invoiced last quarter, but not what the West invoiced. Your chart of accounts has one row for Sales. You want a second way of cutting the same figures — by region, by cost centre, by the campaign that brought the order in — without inventing four ledger accounts for every one of them.

That second cut is a reporting tag. Settings › Reporting tags is where you define them.

A dimension, not a label

JAI CRM has two things called tags and they do different jobs. A label is the coloured sticker you put on a lead so you can find it again. A reporting tag is a dimension: a named question every transaction answers from a fixed list, so that the answers add up in a report. A label that does not add up is a label; one that does is a dimension.

So a dimension is worth creating only when you intend to total something by it. “Region” and “Cost centre” are dimensions. “Chase this one” is a label.

Who can open the screen

The screen asks for the Settings › Reporting tags permission. Of the shipped role presets only Administrator carries it: the Manager preset takes no settings permission beyond view on Users and Circles, and Sales, Accounts and the rest were never given any. To let somebody else in, open Settings › Roles, edit their role and tick the Reporting tags row.

With View and nothing else the screen is entirely read-only: no New dimension, no Edit, no Value, no + on a row and no Remove — not even the deepest level hint, which is drawn only for somebody who could have added a value there.

Making a dimension

1. Go to Settings › Reporting tags.
2. Press New dimension.
3. Name — what the column will be called in a report. Region, Cost centre, Campaign. Up to 60 characters, and it must be unique in your business.
4. Description — optional, up to 240 characters. It is shown to whoever fills the dimension in on a document.
5. Required before a document goes out — leave this clear for now. Read the section below before you tick it.
6. In use — on by default.
7. Press Save.

A dimension with no values cannot be answered — but nothing stops it being offered. The settings screen’s empty card says it will not be shown on a document until a value is added; the document editor never checks, and draws a dropdown for it containing nothing but Not set.

Adding values

1. On the dimension’s card, press Value to add a top-level value.
2. Name — up to 60 characters.
3. Code — optional, up to 30 characters. Nothing reads it. It is stored, and shown beside the value on this one screen; the field’s own hint calls it a short form for imports and exports, and no import, export or report touches it.
4. Press Add.
5. To put a value underneath another, press the + button on that row. The dialog shows where it will sit before you save it.

Values form a tree, five levels deep at most. A row already at the fifth level shows deepest level in place of its + button. Every row below the top level carries its full ancestry — North / Delhi / Dwarka — so a value four levels down still says where it belongs. On a narrow screen the path is dropped: below 640px only the indent and the corner arrow say there is a parent.

Two values can share a name as long as they sit in different places. North / Central and South / Central are both fine; two Centrals under North are not.

Worked example

Sharma Polymers, Pune, sells through three regional teams and wants its invoiced value split by region, with Maharashtra broken out separately.

1. Settings › Reporting tags › New dimension. Name: Region. Description: Which regional team booked the order. Leave “Required before a document goes out” clear. Save.
2. On the Region card, press Value three times: West (code W), North (code N), South (code S).
3. Press + on the West row and add Maharashtra, then Gujarat.
4. Press + on the Maharashtra row and add Pune and Nashik.

Region now has seven values, three levels deep. The Pune row reads West / Maharashtra / Pune.

Invoice INV-2026-0184 goes to Deccan Hardware, Kolhapur: ₹2,40,000 of goods, GST at 18% of ₹43,200, ₹2,83,200 in total. If that invoice carried West / Maharashtra, the Sales by reporting tag report for the quarter would show ₹2,40,000 against West — the taxable value, not the ₹2,83,200 the customer pays. Every figure in that report is before tax.

Which documents can carry one

A Reporting tags card appears on the document editor, below the totals, for the eleven document types that share it:

• Sales — quotation, sales order, proforma invoice, invoice, bill of supply, retainer invoice, credit note, delivery challan
• Procurement — purchase order, purchase bill, debit note

The card only draws once the document has been saved, because the answer has to hang off a record that exists. It draws nothing at all until your business has one dimension in use — with values or without — so a business that does not use them never sees it.

One answer per dimension per document. The answer sits on the document as a whole: there is no way to tag one line of an invoice differently from another, even though the underlying record keeps room for it.

Nothing else can carry a reporting tag. Not expenses, not payments, not manual journals, not leads or deals — despite what the names in the data model suggest.

Setting a value on a document does not work

This is the thing to know before you plan anything around the feature. The card renders, the dropdowns list your values, and saving a choice fails every time with Could not set that — Something went wrong on our side. Any answers already stored are not shown either, because reading them goes the same way.

The cause is a mismatch inside the product, not anything you have configured: the document editor tells the server the record belongs to a module called sales or /purchase, and the server only recognises the specific document types — invoice, quotation, purchaseBill and so on. It does not recognise either name, and refuses the request.

Making a dimension compulsory

Ticking Required before a document goes out does not stop a draft being saved. The check happens when the document leaves the building — when its status moves to sent, confirmed, issued or accepted. A draft nobody has finished is allowed to be incomplete.

When an answer is missing, the status change is refused with a message naming the dimension: Invoice INV-2026-0184 has no Region against it, and that dimension is required before it goes out.

Two limits on that check:

• It runs on sales documents only. Purchase orders, purchase bills and debit notes go out without it, whatever the tick says.
• It applies to every sales document type at once. A dimension can in principle be restricted to particular modules, but nothing in the product sets that — so there is no way to require Region on invoices but not on quotations.

Which reports can group by one

Exactly one: Sales by reporting tag, under Reports › Sales and CRM. It needs the Sales module switched on and the Invoices — View permission, and that one permission does all the narrowing. The report counts invoices, bills of supply and credit notes, but applies the scope of your invoice right to all three — so credit notes are netted off the figures you are shown whatever your rights on credit notes are, and bills of supply are counted the same way.

What it counts:

• Invoices, bills of supply and credit notes. Quotations, orders, proformas and everything on the purchase side are outside it.
• Taxable value, before GST. A credit note subtracts.
• Anything not in draft, cancelled, void or reversed.
• Documents whose issue date falls in the period you picked.

The Group by control offers three depths — Top level, Two levels, Every value — so “sales by region” can read West rather than forty separate branch rows. Documents with no answer are shown as a Not tagged row rather than dropped, and the untagged figure is repeated in the summary strip even when it is zero, so you can see at a glance whether the total is complete.

Not tagged means not answering the dimension this report is cut by, rather than untagged altogether. A document that answered Cost centre but not Region lands on that row when the cut is by Region — in the money column and in the Documents count alike. That is the right total for the cut and a misleading reading of the row’s name.

Nothing else in the product reads a reporting tag. There is no tag filter on the invoice list, no tag column in any list export, no tag in a pivot, no dashboard tile and no GST return that knows about one. The report itself can be exported to CSV or PDF, and that export carries the cut it was built from.

Who can see records carrying a tag

A reporting tag never changes which records somebody can see. Record visibility is decided by the ordinary rules — who owns the record, where their role sits in the hierarchy, and any data sharing rules — and the tag on the record plays no part in it. Tagging an invoice “North” does not hide it from the South team.

There is a second tier designed to narrow which dimensions and which values a person may choose from: a role would say which dimensions it uses at all, and each person would be held to particular values, so that a regional manager sees Region and only North. Both halves are built and both are read when a value is set. Neither can be filled in.

• No screen and no API accepts the list of dimensions a role may use. Settings › Roles has no field for it.
• Nothing creates the record that holds a person to particular values.
• So the narrowing never bites, and the line on the document card that would read You are shown the values you work with never appears.

In practice: the list of dimensions and their values is readable by every signed-in user in your business, whatever their role — the route that serves it asks for no permission at all. It is the in-use ones only, so a dimension you have switched off is not exposed by it. And it is names only: no figures and no records.

Underneath, the tables holding the dimensions, their values and the answers on documents each carry a row-level security policy of their own, installed by this feature’s own migration. A database session set to one business cannot read another’s rows even if a query forgets to say which business it is asking about — the same second line of defence every other tenant table has.

What happens when you save

• Creating a dimension, and every later change to it — a new name, the required tick, switching it off — is written to the audit log under Settings › Audit log. The entry is a one-line summary, Reporting tag Region changed; the old and new values are not recorded.
• Adding or removing a value is not audited at all. There is no record of who added Nashik or who took it away.
• Switching a dimension off stops it being offered on new documents. Answers already recorded stay, so past reports still add up.
• Nothing is applied backwards. A dimension created in March does not appear on February’s invoices, and there is no bulk way to go back and fill it in.

Removing things

What the screen will not let you do

The list is deliberately small, and worth knowing before you plan a naming scheme you cannot revise:

• Rename a value. Add and remove are the only actions on a row. A typo in a value name is permanent once anything uses it.
• Move a value to a different parent. The server can do it — loop guard, depth check and path rebuild and all — but nothing in the product calls that route.
• Re-order anything. Dimensions and values both carry a sort order the API accepts and no control ever sets, so both list alphabetically — the values inside each level of the tree.
• Restrict a dimension to particular modules. The record keeps room for it and the server honours it, but there is no control — so every dimension is offered on every document type that supports tagging.

Limits at a glance