Start with the exact runtime boundary. A return processor can only use records that match its GSTIN, date/period and supported source type. An e-invoice or e-way-bill action can stage data without ever submitting it. A generic form can save fields that a controlled server action would refuse. Distinguishing those states is faster than treating every missing value as the same problem.
Establish the diagnostic boundary
For a GST return, record the return ID and verify GSTIN, fiscal period/return period and lifecycle state. Then choose one known source document and trace it through posting, tax-transaction capture and the expected child table. Do not use a blank GSTR-3B ProcessedInvoiceValue as proof of failure: current Compute does not populate that header field.
For an integration-dependent document, separate these stages:
- the xMatix action created or staged local data;
- a configured integration consumed it;
- the provider accepted it; and
- a response was written to the original xMatix record.
Evidence from one stage does not prove the next.
GST Console
The GSTIN picker is empty
The widget retains active GSTRegistration records with a nonblank GSTIN. Check the master record and read permission. The query does not independently label “own” versus counterparty registrations, so also verify that only appropriate filer records are active.
A financial year is missing
Normal FY choices are derived from stored GSTFiscalPeriod rows. Create or provision the missing periods. When no rows exist, the widget's current-year fallback is only a navigation default.
Months appear but cards open an empty list
The console synthesizes a twelve-month scaffold when stored periods are absent, and a card falls back to a scoped list if no exact return header exists. Provision the required registration/period. For an ISD, remember that the widget still shows annual GSTR-9 while the provisioning service does not create it.
GSTR-1 and GSTR-2B
A source document is missing
Check in this order:
- Posting: Draft source documents do not contribute tax transactions.
- Date: the document must fall inside the return's period.
- GSTIN: the source and header must belong to the same filing registration.
- Source type: GSTR-1 books data comes from supported outward records; GSTR-2B books data comes from supported purchase records.
- Latest processing: rerun the incremental processor after a late posting.
- GSTR-1 row flags: an Ignore or Carry Forward decision removes the document from the current return (a carried-forward document moves to next month's return). There is no button to undo a decision.
GSTR-1 processing is refused
The return is probably Filed. The Process action validates that state and the service blocks regeneration. Correct the source in the appropriate open-period/amendment process rather than reopening the stored snapshot.
GSTR-1 shows no ARN
A GSTR-1 filed through the GSP (Submit File to GSTN) stores the ARN GSTN returns in its ARN field, and the GST Console's filing activity shows it. A return filed on the portal and only recorded here (the manual filing action) stores IsFiled, Status and Filing Date but no ARN — keep the portal acknowledgment in your controlled filing evidence.
GSTR-2B Accept/Reject is missing or disappears on reload
The backend supports Get, Process and Reconciliation only. It has no Accept/Reject/reason/reviewer action. Legacy grid choices change local screen state and are not persisted. Only an ImsStatus value supplied on the row by an authoritative import/integration affects downstream filtering.
GSTR-3B
Box 3.1 is zero even though GSTR-1 is Draft
Draft status alone is not the cause. Compute selects a same-GSTIN/same-period GSTR-1, ordering Filed before Draft. If no Filed record exists, it can use Draft. Identify the selected record and confirm that its processed child rows contain the expected supported supplies.
A different GSTR-1 was selected than expected
Multiple headers exist for the same GSTIN and period. Compute prefers Filed, then uses filing date and record identity to resolve ordering. Remove the duplication through an approved data-cleanup process or make the intended record's lifecycle unambiguous before recomputing.
A credit is missing from 4A
Confirm the latest matching GSTR-2B contains the row and inspect its stored IMS status. R is excluded. Do not look for an xMatix Reject audit record—the current workflow does not create one. If the credit is ledger-classified as blocked, inspect the 4B reversal evidence separately.
Processed Invoice Value is blank after Compute
This is current behavior. Compute sets Status to Computed and writes child-table rows but does not assign GSTR-3B's ProcessedInvoiceValue. Validate the child tables and source totals instead. The scheduled job has a different readiness check: it tests non-null processed values on GSTR-1 and GSTR-2B, not this GSTR-3B field.
A manual value disappeared
Compute clears and rebuilds rows marked auto-filled while preserving manual rows. Confirm that the value was entered in a truly manual row such as 3.1.1 or a Rule 42/43 adjustment, rather than editing an auto-filled row directly.
A payment row changed after Compute
Compute upserts payable for the four tax heads while retaining cash and credit-utilization fields on existing rows. Reconcile the refreshed payable amount with the liability, then verify the retained payment allocation against portal ledgers.
ITC and Rule 37
Where is the ITC availment or Rule 42 action?
It is not currently exposed. Source services exist for an ITC-ledger lifecycle and Rule 42 calculation, but no runtime handler, page or scheduled caller invokes them. Use the implemented GSTR-2B/GSTR-3B path and retain a manual Rule 42 workpaper.
A Rule 37 reversal appeared unexpectedly
Inspect the linked Bill, its document date, open amount and applied payments. The GSTR-3B compute path treats an eligible Bill as overdue after 180 days and relies on recorded settlement evidence. A payment not applied to the Bill may leave it appearing unpaid.
A paid Bill did not reclaim
Confirm the Bill's open amount is no longer positive and payment linkage is present. Then Compute an open GSTR-3B and inspect whether the tracker already records reversed-in and reclaimed-in periods.
E-invoicing
The Invoice stays at Ready For IRN or Pending
xMatix recorded the request but does not submit it. Verify that the configured integration reacts to Status (eInvoice) Ready For IRN (the web panel) and Pending (the action run directly), and writes the IRN, acknowledgement and QR back to the same Invoice. A rejection's reason is in Response (eInvoice).
The provider rejects party address, Unit or service classification
Inspect the actual payload. The built-in builder leaves seller and buyer legal name, location and PIN blank and the line unit blank, and classifies each line as goods or a service from its Is Service flag (blank counts as goods). The integration must add the missing values where the provider requires them.
Generate is refused
The Invoice already has an Invoice Reference Number (eInvoice). That is the duplicate-generation guard. It is not a general edit lock and does not perform portal cancellation.
A registered Invoice can still be edited
The e-invoice service does not impose a global Invoice lock after IRN. Restrict edits through permissions and document lifecycle controls, and use the proper statutory correction process.
E-way bills
A row remains Draft with no EWB number
The Invoice action created local Part A data only. Verify that a configured provider flow submitted it and called the generated-response writeback for that EWayBill ID. The generic entity form does not perform this transition.
Distance is zero or transporter data is blank
Distance defaults to zero, Road is the default mode, and the Invoice action leaves transporter ID/name blank. Supply and validate the transport facts before submission.
Duplicate Draft rows exist
The Invoice action has no existing-row guard. Do not generate another Draft as a retry. Select one intended ID under an approved cleanup process and make the integration write back only to it.
A past-validity row still says Generated
No runtime job changes Generated to Expired, and no cancellation action was found. Use the portal as authority and treat status synchronization/expiry alerting as an integration gap.
Form 26AS
Attaching a file creates no lines
No parser reads the file and nothing validates lines. Import the rows as Form 26AS Lines linked to the statement (the console's Upload 26AS does this through the standard import), and set each line's Validation Status yourself. Total Rows, Valid Rows and Error Rows are filled in when you reconcile. See TDS reconciliation.
The reconciliation is refused for PAN
The statement is tied to the company whose account PAN matches the PAN on its lines. "No company has PAN …" or "More than one company has PAN …": set or correct the PAN on the company account. "The 26AS lines carry more than one PAN": split the rows into one statement per PAN. Then reconcile again.
Every group is Missing in books
The books side is the company's TDS receivable: non-reversed TDS rows posted from its sales invoices in that financial year. If there are none, the invoice lines carry no TDS section, or the receivable was posted under another company.
A group is TAN missing, or Missing in 26AS with a "no TAN on file" remark
The customer's account has no TAN. Set the TAN the remark names on the customer account, then reconcile again.
A group stays Not final although the TDS agrees
TRACES has booked a line U, P or O, so the credit is not claimable yet. Download the Form 26AS again after the deductor corrects their filing, upload it as a new statement and reconcile; follow up with the deductor if it stays.
The older Form 26AS widget and the console disagree
They use different algorithms. The older widget groups by TAN only, compares TDS client-side over every TDS row, and keeps its row marks on screen only. The console reads the saved results: the company's TDS receivable, grouped by PAN, TAN, section and financial year, decided on TDS within ₹1, with decisions kept on the entries. Use the console.
TDS challans and returns
A Deposited or Verified challan can still be edited
The challan actions never change a deposited challan's amounts, but saving the record does not freeze a deposited challan or its amounts. Restrict edit permission and audit changes; status alone is not an immutability control.
One month produced two challans for the same payment code
Challans are grouped by payment code and major head. Company and non-company deductees can therefore produce separate valid challans for one payment code.
A challan cannot be deposited, verified or corrected
Each refusal message and its fix — missing bank account, missing control accounts, a challan with no deductions, and the CSI and correction inputs the shipped screen cannot supply — is listed under Common problems in TDS challans.
Return validation fails
Read the exact validation result. Common supported checks include missing/invalid PAN, an undeposited deduction, incomplete CIN, challan over-use/short deposit and missing lower-deduction certificate data. Correct the named source and recompute rather than editing a Filed return line.
A Filed TDS return needs a change
Use the correction-return path. Deductor-side reconciliation can also classify a Filed line with no live books row and offer the relevant server remediation when its state and IDs permit it.
Still stuck?
Confirm both code availability and tenant metadata. Handlers can exist without a metadata action being exposed, and screens/actions are permission-gated. Check the user's security profile before assuming a missing button is a calculation defect.