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 selected books row from the current filing. The clear-decision service is not currently exposed as a handler action, so do not promise an Undo button.
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 has no acknowledgment field
This is expected. The filing action stores IsFiled, Status and Filing Date only. Retain ARN/portal acknowledgment in your external controlled evidence; it cannot be recovered from the GSTR-1 header.
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 remains Pending
The Invoice action staged EINVPayload; it did not submit it. Verify that an explicitly configured integration consumes Pending Invoices and writes success back to the same Invoice. The built-in response recorder requires an IRN and has no failure-recording companion, so inspect the integration's own error/audit path for a rejection.
The provider rejects party address, Unit or service classification
Inspect the actual payload. The current builder leaves seller/buyer legal name, location and PIN null, leaves Unit null and sets every line IsService = false. The integration or product mapping must enrich/correct those values where required.
Generate is refused
The Invoice already has EINVIRN. 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 or row counts
No runtime parser or Form26ASLine handler exists. Import Form26ASLine explicitly and validate the file outside the generic header form. The backend reconciliation updates match counts, not Total/Valid/Error counts.
The Form 26AS widget and saved reconciliation disagree
They use different algorithms. The widget groups by TAN and compares rounded TDS client-side; the backend groups by PAN, TAN, section and financial year and compares both Amount Paid and TDS with zero tolerance. Widget remediation labels are screen-local and disappear on reload.
TDS challans and returns
A Deposited or Verified challan can still be edited
The Correct Challan action restricts changes to head/code/CIN/deposit-date fields and logs them, but the generic entity save validator does not freeze a posted row or its amounts. Restrict generic 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.
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.