Extract Indian Bill of Entry to Excel for ITC & Landed Cost

You convert a Bill of Entry to Excel in India by pulling two layers of data out of the PDF. The header layer gives you the BoE number, BoE date, port code, the importer's name with GSTIN and IEC, the supplier, the invoice or CIF value with its currency, and the exchange rate. The line layer, repeated for every item, gives you the CTH/HSN code, the assessable value, and the duty stack: Basic Customs Duty (BCD), Social Welfare Surcharge (SWS), and Integrated GST (IGST), plus any anti-dumping or safeguard duty and cess where they apply. Add the totals, and that is the full record. Those columns are the whole job.

The reason to pull them is that the same data feeds two spreadsheets every importer's accountant has to produce. The first is an import-IGST input tax credit register that you reconcile against the IMPG (Import of Goods) section of GSTR-2B. The second is a duty-inclusive landed-cost sheet, where the order of operations matters: the assessable value comes first, then BCD is charged on the assessable value, then IGST is charged on the assessable value plus BCD. Get those two sheets right and the BoE has done everything it needs to do in your books.

The document itself is the Bill of Entry for Home Consumption, generated through ICEGATE when the consignment is assessed for clearance. You already know what it is and why you need the numbers off it. The problem is that re-keying a dense, multi-page assessment document, line by line, across a recurring pile of imports, is slow and error-prone, and the field set above is exactly what you have to capture each time.

So the task this article addresses is narrow and practical: take the Bills of Entry you already hold and turn a batch of them into exactly the columns these two jobs need. Not computing duty from scratch, not accepting a fixed output template built for someone else's purpose, but extracting your fields into your layout. The rest of this guide walks through getting a batch into Excel, then building each of the two spreadsheets, then the reconciliation and posting steps that consume them.

---

Getting a Batch of Bills of Entry Into Excel

The practical way to get the field set into a spreadsheet is to describe the columns you want and run that description over the whole folder of BoEs at once, rather than re-typing each document or feeding them in one at a time. You name the header fields and the per-line fields you settled on, say whether you want a row per BoE or a row per item, and get back a structured Excel or CSV in your own layout. The columns are yours to define, which matters because the two jobs ahead need different shapes from the same source document.

The hard part is the multi-page structure. A single Bill of Entry for Home Consumption often runs to several pages, with a header block once and then many item lines that may spill across page breaks. The data has to come out as one header record, carrying the BoE number, date, port code, GSTIN, IEC, CIF value, exchange rate, and totals, plus a repeated row for each item line carrying its CTH/HSN, assessable value, BCD, SWS, and IGST. The duty has to stay allocated to the correct line, and the foreign-currency unit prices and the exchange rate have to be captured together so the rupee values reconcile back to the assessed totals. This is where a naive page-by-page approach falls apart and where multi-page bill of entry extraction earns its place.

It is worth being clear about what this replaces. The free single-file converters that rank for this query take one PDF in and hand back a fixed-template Excel, usually shaped to generate a purchase ledger or an e-Way Bill, with no say over the columns or the downstream purpose. That is fine if the template happens to match your job and you only have one document. It does not help when you have a stack of BoEs and two different sheets to build from them. Defining your own columns and running a batch in one pass is the difference between a tool that dictates your output and one that fits your workflow.

This is the step where you extract a batch of Bills of Entry into your own Excel layout: you upload the documents, describe the header and line fields you need in plain language, and download a structured file. Invoice Data Extraction handles batches of up to 6,000 mixed files in a single job and single PDFs up to 5,000 pages, so a quarter's worth of multi-page BoEs goes through in one task with the same prompt. Output comes as Excel, CSV, or JSON, and every row carries a reference back to its source file and page number, so when a figure looks wrong you can open the exact BoE page it came from. The import side mirrors the domestic side here; the same approach lets you extract Indian purchase invoices to Excel for your local purchase register, and on the outward side it lets you pivot HSN-wise sales data into the GSTR-1 Table 12 summary the same way you roll BoE lines up by CTH.

For most importers, two output shapes cover the work. One row per BoE gives you a register-level view, suited to the IGST credit reconciliation. One row per line item, with the BoE number repeated on each row, gives you the CTH-level and landed-cost-per-line detail the costing sheet needs. You can run the same batch twice with different column instructions, or extract at line level once and roll up to BoE level in Excel.

Building the Import-IGST ITC Register and Reconciling It Against GSTR-2B

The credit register is the first sheet the extracted data builds. At its simplest it is one row per BoE carrying the BoE number, port code, BoE date, GSTIN, assessable value, and IGST amount. Those are precisely the fields you need both to claim the import IGST as input tax credit and to substantiate it if the claim is ever questioned. Where a single BoE covers goods you want to track separately, you can hold it at line level and sum the IGST up to the BoE, but the five matching fields plus the IGST amount are the backbone.

What makes this register the thing you reconcile against, rather than a convenience, is how the import credit reaches the return in the first place. Import IGST paid on a Bill of Entry is auto-populated into GSTR-2B in the IMPG (Import of Goods) section, updated on a near real-time basis from the ICEGATE customs system, showing each BoE's port code, number, date, taxable value and tax amount, as set out in the GST portal's GSTR-2B guidance on import-of-goods records. So the portal already holds a view of your import credit. Your job is to confirm it matches the BoEs you actually cleared, and the matching keys are exactly the register's columns: BoE number, port code, BoE date, GSTIN, and IGST amount all have to agree between your register and the GSTR-2B IMPG lines.

The reconciliation matters because import IGST sits in its own section, away from domestic purchases, and follows its own transmission path. The same discipline you apply when you reconcile GST input tax credit against GSTR-2B and IMS for local supplies applies here, but the import lines are populated from ICEGATE rather than from a supplier's GSTR-1, so the failure modes are different.

The one to watch is partial transmission: a BoE you have cleared and paid IGST on simply does not appear in GSTR-2B IMPG, and the credit goes missing until you chase it. The usual causes are a GSTIN mismatch on the BoE, a BoE that has not been finalised, or an invalid port code or BoE-number format that ICEGATE cannot transmit cleanly. The practical levers are the GST portal's self-service function to search a BoE and fetch it from ICEGATE, and the timing caveat that an entry should not be expected for roughly five days after the BoE date before you treat it as missing. A register built from your own extracted BoEs is what tells you which entries to chase, because it is the independent list of what should be there.

From October 2025 the path also runs through the Invoice Management System. Bills of Entry now flow into the IMS under its Import of Goods section for you to accept or leave pending, with the draft GSTR-2B generated on the 14th, so import credit can be verified inside IMS rather than only through manual ICEGATE reconciliation. Either way, the extracted register is the record you check those IMS or GSTR-2B import lines against, line for line.

Building the Landed-Cost Sheet From the Duty Stack

The landed cost from a bill of entry is built in a fixed sequence, and the sequence is what most blank templates and duty calculators get wrong or skip. The assessable value comes first: it is the CIF figure, which is FOB plus freight plus insurance plus landing charges. BCD is charged on that assessable value, and SWS is charged on the BCD. IGST then sits on top of the lot, levied on the assessable value plus BCD plus SWS rather than on the assessable value alone, with any cess following the same compounding logic. Landed cost is then the CIF value plus BCD plus SWS plus IGST plus cess. Lay the columns out in that order and the arithmetic on the BoE reconciles to the assessed totals.

One distinction decides what actually lands in your inventory cost. IGST is recoverable as input tax credit, the subject of the register in the previous section, so it is normally excluded from the cost you carry into stock. BCD, SWS, and cess are not creditable, so they become part of the landed cost of the goods. A clean costing sheet therefore separates the creditable IGST from the non-creditable duties, even though both are extracted from the same BoE.

In practice you want this at line level. Carry one row per item with its CTH/HSN, assessable value, BCD, SWS, IGST, and cess, then a computed landed-cost column that applies the build-up above. Where line-level costing is more detail than the goods warrant, a per-BoE roll-up works, but a per-line sheet is what lets you cost each SKU or material grade accurately. Because you extract BCD, SWS, IGST, and the assessable value straight from the BoE per line, the landed cost is built from the figures customs actually assessed, not re-derived by typing an HSN code and a CIF value into a calculator and hoping the duty rates match what was levied. That is the gap the calculators leave open: they compute duty from inputs you supply, whereas the BoE already carries the assessed numbers, and extracting BCD, SWS and IGST from the bill of entry is what puts them in your sheet.

---

Matching the Bill of Entry to the Commercial Invoice and Weighbridge Slips

For many importers the BoE is the whole story, but for commodity and heavy-industry buyers it is one document in a set, and the set has to agree with itself. The first match is against the supplier's commercial invoice: the CIF value, currency, and per-item descriptions and quantities on the invoice should line up with what the BoE was assessed on. When you match the bill of entry to the supplier commercial invoice and the figures diverge, you have either a valuation question to resolve or a transcription error to fix before the credit and the cost are booked on numbers that do not tie out.

For bulk goods there is a second match, on weight. A metals or copper-scrap importer reconciles the net weight on the local weighbridge slip against the gross weight and customs value on the BoE, with IGST, SWS, and cess sitting in the duty stack, and cross-checks the Container Corporation gatepass. The point of the bill of entry versus weighbridge and gatepass reconciliation is to confirm that the quantity and value hold across the entire import set, not just on the assessment document, because for scrap and raw materials the weight is the commercial substance of the consignment.

The obstacle is document quality. Weighbridge slips are usually thermal-printed, faint, and often carry handwritten annotations over the printed figures, which is the genuinely hard part of pulling them into the same reconciliation sheet as the clean, machine-generated BoE. This is where extraction has to cope with more than a tidy PDF: Invoice Data Extraction interprets data from lower-quality scans and mobile-phone photographs, and can be instructed to prioritise handwritten notes over the original typed text, so a marked-up thermal slip can be read into the same structured columns as the BoE rather than re-keyed by hand. The terminal and clearing-side documents round out the picture; you can also extract ICD/CFS terminal and CHA invoices so the freight, handling, and agency charges sit alongside the BoE and the weighbridge data in one cost view.

Posting the Extracted Bill of Entry Into Tally

In Tally an import is booked as a purchase voucher that carries the BoE number, the BoE date, and the port code, with the duty and charges attached to item cost through the Additional Cost of Purchase mechanism. That is how the landed cost you built in the costing sheet actually loads against the goods rather than sitting in a separate ledger. Setting up the bill of entry to Tally import purchase voucher is the posting step that turns the two spreadsheets into book entries.

The extracted data is what you key in. The per-BoE register fields, BoE number, date, and port code, supplier, assessable value, and IGST, populate the voucher header and the reference fields, and the per-line landed-cost columns provide the additional costs allocated across the items. Because those values came out of the BoE once, into your own layout, you are not re-reading the assessment document a second time at the posting stage; the spreadsheet is the bridge between the customs document and the voucher.

Keep the IGST treatment consistent with the credit register. The import IGST is posted so that it is claimed as input tax credit, not folded into item cost, while BCD, SWS, and any cess flow into the landed cost that attaches to the goods. The detailed mechanics of getting structured purchase data into the ledger, including the Additional Cost of Purchase entries, are covered when you import purchase vouchers into TallyPrime.