How to Build a GSTR-3B Working Paper from Invoice Data
Dynamite Docs, 2026-08-14
Build the GSTR-3B monthly summary from transaction detail
A GSTR-3B monthly summary should be the last layer of a GST monthly summary working paper, not the first. Start with reviewed transaction rows for the tax period, map those rows to reviewer-approved categories, and calculate each summary from that detail. A total with no trace back to invoices, notes, adjustments, or portal data is difficult to verify and harder to correct.
The GST Portal describes GSTR-3B as a summary return used to declare and discharge GST liabilities for a tax period. The return covers more than sales and purchase totals. The visible sections depend on the taxpayer's facts and can include outward supplies, reverse-charge inward supplies, inter-state details, eligible ITC, exempt or non-GST inward supplies, interest or late fee, and payment.
Dynamite Docs can extract source fields and prepare reviewable rows. It does not determine tax liability, decide input tax credit eligibility, calculate the amount to pay, or file GSTR-3B. The taxpayer and qualified tax professionals own those decisions.
- Detail tables preserve each sales invoice, purchase invoice, credit note, debit note, and adjustment.
- Mapping columns record the proposed GSTR-3B category and reviewer decision.
- Summary tables group accepted rows by category and tax head.
- Control tables reconcile books, GSTR-1 or GSTR-1A, GSTR-2B, portal values, and the draft return.
Create separate outward and inward detail tables
Use one outward table for sales-side documents and one inward table for purchase-side documents. Each row should retain the document number and date, counterparty GSTIN where relevant, document type, place of supply, HSN or SAC context, taxable value, CGST, SGST, IGST, cess, invoice value, source file, page, and review status.
Include credit notes, debit notes, amendments, reverse-charge items, imports, exempt or nil-rated items, and other relevant records as distinct types. Do not net them silently into an invoice total. A separate row preserves the period movement and gives the reviewer enough context to apply the correct treatment.
Attach a stable key to the document header and any item rows. Normalize dates, number formats, and identifiers in helper columns while preserving the source text. Leave unreadable or missing values blank with an exception reason instead of guessing.
Reconcile the source population before classifying rows
Compare the extracted population with the sales register, purchase register, and other accounting records for the same period. Check document counts, document types, date coverage, and gross values. Missing source files, duplicate scans, cancelled documents, and transactions recorded in another period should remain visible in an exception schedule.
Recalculate item and document totals where the source has enough information. Compare taxable value and each printed tax component with the invoice summary, allowing only documented rounding differences. A row can balance arithmetically and still have the wrong classification, so arithmetic review comes before tax review rather than replacing it.
Freeze a reviewed population before building summaries. Record which rows are accepted, rejected, deferred, duplicated, or awaiting evidence. This stops the underlying dataset from changing while someone is checking the return.
Map reviewed rows to GSTR-3B working categories
Add reviewer-owned columns for the proposed GSTR-3B section, tax head, eligibility status, reason, reviewer, and decision date. The extractor should not assign these values from keywords on an invoice. Place of supply, reverse charge, ITC eligibility, exemptions, and other treatment can depend on facts outside the document.
Keep the extracted value beside any corrected value and the final accepted value. If the reviewer changes a category or amount, preserve the original source, correction, reason, and owner. This creates an audit trail and makes later reconciliation possible.
Build subtotals only from accepted rows. Group by the working categories required for the draft return and retain a drill-down from every subtotal to its source records. If one row feeds more than one control, document the rule so it is not counted twice.
Compare GSTR-1, GSTR-2B, and system-generated GSTR-3B
The GST Portal auto-populates parts of GSTR-3B from filed GSTR-1 or GSTR-1A and generated GSTR-2B data. Official guidance says those values assist taxpayers, remain editable, and still need taxpayer verification. Download the system-generated GSTR-3B detail and compare it with the working paper rather than copying it as the answer.
On the outward side, compare the reviewed sales summary with GSTR-1 or GSTR-1A and the portal-generated liability values. On the inward side, compare purchase records with GSTR-2B and the proposed ITC treatment. Record every difference by category and tax head with an owner and explanation.
Timing, amendments, credit notes, reverse charge, missing supplier filings, and classification decisions can create genuine differences. Do not force the books to equal the portal by overwriting source data. Preserve both values and let the responsible tax reviewer decide the adjustment.
Run control checks before payment review
Tie each GSTR-3B working total back to accepted detail rows. Recalculate outward taxable values, inward values, eligible and ineligible ITC working amounts, reverse-charge items, and CGST, SGST, IGST, and cess totals according to the approved mapping. Compare the draft with the accounting ledgers and portal summary.
Use a control sheet that shows book value, portal value, draft return value, difference, explanation, evidence link, reviewer, and status. A zero net difference can hide offsetting errors, so review material category and tax-head differences before relying on the grand total.
Lock the reviewed workbook version and record approval before the payment stage. Interest, late fee, cash-ledger use, credit-ledger use, offset order, challan creation, and final payment need current portal information and professional review. Do not calculate or recommend payment from extracted invoice data alone.
- Accepted row counts agree with the frozen outward and inward populations.
- Every summary subtotal has a drill-down to source records.
- Book, GSTR-1 or GSTR-1A, GSTR-2B, and portal differences have explanations.
- Tax heads, signs, periods, credit notes, and amendments have been reviewed.
- The payment reviewer receives the approved version and open exception list.
Preview the draft return and preserve the review record
The GST Portal provides a draft GSTR-3B preview before payment and filing. Compare that preview with the approved working paper section by section. If someone edits an auto-populated value, record the prior value, revised value, reason, evidence, and approver in the control sheet.
Save the source exports, reviewed transaction tables, system-generated GSTR-3B detail, mapping version, draft preview, exception schedule, and approval record together. The final return and payment confirmation can then be added to the same period file after the authorized person completes filing.
A clean review package does not remove the need for tax judgment. It makes that judgment traceable. The reader should be able to move from a draft return value back to the reviewed documents without reconstructing the month from email attachments.
Use current GST Portal guidance for GSTR-3B
The GST Portal GSTR-3B FAQ explains the return, auto-populated values, downloadable system-generated detail, and taxpayer review responsibility. The filing manual shows the return sections, draft preview, payment stage, and filing flow. The GSTR-2B FAQ explains the purchase-side statement and its role in auto-populated GSTR-3B information.
Check those sources for the relevant tax period. Portal behaviour, return questions, interest handling, and filing requirements can change. A qualified professional should review the facts, current law, and final return before payment or filing.
- GSTR-3B definition and auto-population controls (Source: GST Portal: Form GSTR-3B FAQs)
- Draft preview, payment, and filing steps (Source: GST Portal: Create and Submit Form GSTR-3B)
- Purchase-side statement and GSTR-3B data flow (Source: Form GSTR-2B viewing and reconciliation FAQs)
Frequently asked questions about the GSTR-3B working paper
These answers keep extraction, reconciliation, tax review, and filing in the right order.
- Can invoice extraction prepare and file GSTR-3B? It can prepare source rows and working summaries. The taxpayer or tax professional must decide classifications, ITC, liability, payment, and filing.
- Should I accept auto-populated GSTR-3B values without checking? No. GST Portal guidance describes them as assistance and states that taxpayers must ensure the reported values are correct.
- Why keep invoice rows for a summary return? Detail rows explain each total, expose duplicates and period errors, and give reviewers evidence for corrections.
- Can a balanced monthly total still be wrong? Yes. Offsetting errors, wrong tax heads, incorrect periods, duplicate documents, or classification mistakes can produce the same net amount.
- What should happen to unresolved differences? Keep them in the exception schedule with an owner, evidence, and decision status. Do not hide them by changing source values.
Close one GSTR-3B working paper before repeating the process
Start with one tax period. Build the outward and inward detail tables, reconcile them to the books, apply reviewer-owned mappings, compare GSTR-1 or GSTR-1A and GSTR-2B, tie every summary to accepted rows, and review the portal draft before payment. Preserve the final evidence and exceptions.
Dynamite Docs can support GST invoice extraction into Excel, CSV, JSON, or Google Sheets for that review. The useful outcome is not a guessed return. It is a GSTR-3B working paper where every monthly summary value is traceable and every tax decision has an accountable reviewer.
Sources checked for this note
Related workflow: GSTR-1 invoice data preparation.
Keep reading
Try it yourself. Upload a PDF, scan, or image and let Dynamite Docs infer the schema.