Tools  /  Export invoice extractor
Free tool

Read every field out of an export invoice PDF.

The number, the date, the currency, the parties, the terms and every line, with the invoice checked against its own arithmetic. Free, and the file is kept so the reader keeps getting better.

Free, no sign-up

No account, no email box, no card.

Stored

Kept so the extractor keeps getting better.

10 of 10 free reads left today

Resets at midnight IST.

What comes back

The result, as an outline. Every cell says what would sit in it; the values appear when you drop a file.

The fields a realisation filing asks for

Document identity

Invoice numberThe invoice's own serial, up to twenty characters
Invoice dateDay, month and year

Amounts

CurrencyThree-letter currency code
Invoice totalThe total the buyer owes, in the invoice currency
SubtotalBefore tax and charges
TaxTax charged, if any

Charges and deductions

FreightIf charged
InsuranceIf charged
DiscountIf granted
CommissionIf shown

The invoice, checked against itself

What was checkedThe document saysWorked out from the restResult
Each lineThe line's amountIts quantity times its rate
The linesThe subtotalThe sum of the lines
The totalThe invoice totalSubtotal plus tax and charges, less discount
Invoice numberIts lengthTwenty characters at most

The rest of the trade

  • ExporterName and address, GSTIN, IEC
  • BuyerName and address, country of destination
  • TermsDelivery terms, payment terms, purchase order
  • ClassificationThe classification code for the goods or service
  • Bank detailsAccount number and bank code
  • Line itemsOne row per line: description, HS code, quantity, unit, rate and amount
The file is stored

It is kept so the extractor can be improved against the real documents people upload, which is how the parsers get better at the layouts customs actually produces. There is still no account, no email box and no card.

No account, and nothing to sign

There is no sign-up wall, no email box, and no cookie set for this. Ten invoices per internet connection a day, resetting at midnight IST, which is the ceiling that keeps the tool free for everyone. An office sharing one connection shares the ten.

The same reader the product uses

This is not a demonstration version. It is the reader behind the eBRC exporter app and the documented extraction API, answering here with nothing held back.

What the export invoice extractor does

The export invoice extractor reads an export invoice PDF and returns every field on it, the invoice number, date, currency, parties and terms, and each line item as its own row, as a CSV or as JSON, free and with no sign-up. It is export invoice data extraction without the retyping: drop the PDF, the fields come back.

Open the CSV in Excel. The download is a comma-separated file, and Excel and Google Sheets open it directly. The fields come as one CSV and the line items as another.

What an export invoice is, and why its fields matter later

An export invoice is the commercial document that says what was sold, to whom, for how much and in which currency. It is raised by the exporter, it travels with the consignment or with the service, and it is the document every later step in the export points back at: the buyer pays against it, the bank quotes it when the money lands, and the realisation certificate is certified against it.

That is why reading one correctly is worth a page of its own. An invoice number typed with a character wrong, or a total read off the line above the one that carries it, does not fail loudly. It fails weeks later, when a payment arrives that nobody can match to a document, or when a certificate cannot be mapped to the remittance it belongs to.

This tool reads the PDF and hands back every field it finds, grouped so the values a filing needs come first, and it does the arithmetic the invoice implies so you find out here whether the document agrees with itself.

The fields this tool reads, and what each one means

The first group is the set a realisation filing asks for. The second is the rest of what the invoice says about the trade, which is what somebody reconciling a payment reaches for next.

Invoice numberThe invoice's own serial, up to twenty characters

The exporter's own serial for this invoice. It is the reference the remittance is mapped against, so it has to match the number the buyer quotes when they pay and the number the bank sees on the advice.

Invoice dateDay, month and year

The date of issue. It is the date a filing carries beside the invoice number, and the date everything later, from the buyer's payment run to the certificate, refers back to.

CurrencyThree-letter currency code

The currency the invoice was raised in. It has to be the currency the payment arrives in, because a filing states the invoice value and the remittance in the same currency code.

Invoice totalThe total the buyer owes, in the invoice currency

The total the buyer owes, in the invoice currency. This is the figure a realisation is measured against, and the one a part payment is measured as a share of.

SubtotalBefore tax and charges

The value of the goods or services before tax and before any charge added at the bottom of the invoice. It is what the line items should add up to.

TaxTax charged, if any

Tax charged on the invoice. An export invoice raised under a letter of undertaking carries none, and one raised on payment of integrated tax carries it here.

FreightIf charged

Freight charged on the invoice. A filing can state freight separately and deduct it, so reading the printed figure beats remembering it.

InsuranceIf charged

Insurance charged on the invoice. It is the second of the four amounts a filing can state separately and deduct.

DiscountIf granted

Any discount the invoice grants. A discount agreed after the invoice was raised is the most common reason a payment arrives smaller than the invoice and still closes it.

CommissionIf shown

Agency commission shown on the invoice. Where an agent's commission is deducted before the money reaches India, this is the figure that explains the shortfall.

ExporterName as printed

The supplier, which on an export invoice is you. The name and address of the supplier is one of the particulars a tax invoice is required to carry.

Exporter GSTINFifteen characters

The supplier's GST identification number, fifteen characters. A filing that claims the GST benefit has to name the GST invoice number and its date, so this is the field that tells you which invoice series you are in.

IECTen characters

The Importer Exporter Code of the exporter, ten characters. Every certificate ends up under one IEC, so an invoice that prints it saves a lookup later.

BuyerName as printed

The overseas recipient. On an export invoice the name and address of the recipient are required in place of the domestic recipient details.

Country of destinationCountry name

Where the goods or services are going. An export invoice is required to carry the name of the country of destination, and it is the first thing anyone reconciling a remittance looks for.

Classification codeThe classification code as printed

The classification code for what was supplied, the goods code or the services code. A service export filing carries the services code, so an invoice that prints it is the one document that already holds it.

Delivery termsThree-letter delivery term

The delivery term the price was agreed on. It decides whether freight and insurance are inside the invoice value or outside it, which is exactly what the deduction fields in a filing are for.

Payment termsAs printed

When the money is due. It is the difference between a payment that is late and a payment that was never coming, and it tells you when to expect the remittance the certificate needs.

Purchase orderThe buyer's order reference

The buyer's own order reference. It is often the only string the buyer's accounts department quotes when they pay, which makes it the key that matches a payment to this invoice.

Bank accountAccount number as printed

The account the invoice asks to be paid into. The remittance has to land in an account your authorised dealer bank reports, or the inward remittance never appears against your IEC.

Bank codeBank identifier code

The code the buyer's bank routes the payment to: the international bank identifier, or the IFSC for a payment routed within India. A wrong one is the most ordinary reason a payment sits somewhere for a week and arrives short of a charge or two.

What an export invoice has to carry

An invoice raised by a registered person in India is not a free form document. Rule 46 of the Central Goods and Services Tax Rules, 2017 lists the particulars a tax invoice must contain, and the list is worth knowing because it is exactly the set a reader can expect to find.

The rule requires the name, address and GSTIN of the supplier; a consecutive serial number not exceeding sixteen characters, unique for a financial year; the date of issue; the classification code for the goods or services; the description; the quantity and unit for goods; the total value of the supply; the taxable value after any discount; the rate and the amount of tax; the place of supply; and the signature or digital signature of the supplier or an authorised representative.

For an export the rule changes twice. The invoice carries an endorsement, either "SUPPLY MEANT FOR EXPORT/SUPPLY TO SEZ UNIT OR SEZ DEVELOPER FOR AUTHORISED OPERATIONS ON PAYMENT OF INTEGRATED TAX" or "SUPPLY MEANT FOR EXPORT/SUPPLY TO SEZ UNIT OR SEZ DEVELOPER FOR AUTHORISED OPERATIONS UNDER BOND OR LETTER OF UNDERTAKING WITHOUT PAYMENT OF INTEGRATED TAX", as the case may be. And in place of the domestic recipient details it carries the name and address of the recipient, the address of delivery, and the name of the country of destination.

The export invoice format guide assembles the whole document, with what customs and the bank need on top of the rule.

The sixteen character serial is a detail worth holding on to. A realisation filing carries the invoice number in a twenty character field, so an invoice number that follows the rule always fits. The invoice numbers that do not fit are the ones built from a project code, a buyer reference and a running number joined together, and they are also the ones a bank truncates on the remittance advice. The tool says so when it sees one.

The three sums this tool checks

An invoice states its numbers more than once, so it can be tested against itself. Three sums are worth doing every time, and all three are done here.

Quantity times rate, on every line

The oldest error on an invoice and still the most common. A quantity is edited after the amount was typed, or a rate is agreed at a discount and only the total is updated. Every line that carries a quantity, a rate and an amount is multiplied out, and any line where the three do not agree is named by its position with both figures printed, so you can see whether it is a rounding difference or a real one.

The lines against the subtotal

The line amounts are added and compared with the subtotal the invoice states, or with the total when there is no subtotal line. This is the sum that catches a line item that was deleted from the table but not from the total, and the one that catches a second page of items that did not make it into the file.

The subtotal and the charges against the total

The subtotal, plus tax, plus freight and insurance, less discount, should be the total the buyer is asked to pay. When it is not, one of the charges is either double counted or missing, and which one it is usually becomes obvious once the difference is on the screen next to the four figures that made it.

A difference of a hundredth of a unit is rounding and is ignored: two decimal places on a dozen lines genuinely lands a fraction away from a total computed at full precision, and a check that fires on correct documents is a check people learn to skip. Anything larger is reported, with the figures, and left for a person to judge.

What the checks buy you is not certainty. It is knowing which kind of invoice you have before the value travels into a filing, a claim or a buyer's accounts payable queue.

Currency, and why the invoice currency is the one that counts

An export invoice is raised in a currency and realised in one, and a filing states both. When they are the same the mapping is arithmetic. When they are not, somebody has to decide what the difference is: a conversion the buyer's bank made, a charge deducted on the way, or a genuine short payment.

So the currency code on the invoice is worth reading exactly as printed. A filing takes the three letter code, and an invoice that prints a symbol instead of a code leaves the reader to infer which dollar or which krone was meant. The tool reports the currency as it found it and says when it is not a three letter code, which is a small thing that saves an argument later.

Delivery terms, and what they do to the value that gets realised

The delivery term on the invoice decides whether freight and insurance are inside the price or outside it. A price agreed free on board carries neither, and a price agreed with cost, insurance and freight included carries both. The same consignment invoiced on the two terms produces two different invoice totals for identical goods.

That matters after the money arrives, because a realisation is measured against a value, and the value has to be the one that belongs to the goods. This is what the deduction fields on a filing are for: freight, insurance, discount and commission can each be stated and taken out, so the realisation is judged against what the export was actually worth rather than against whatever the invoice happened to bundle in.

Reading those four amounts off the invoice rather than remembering them is the whole point of the group at the top of the result. They are printed on the document, and they are the ones most often retyped from memory.

Service exports, where the invoice is the export document

A goods export has a shipping bill: customs generates it, and it is the reference the export is known by afterwards. A service export has nothing of the kind. There is no consignment, no port, and no customs document, so the invoice is the export document, and the invoice number and date are what the inward remittance is mapped against when the certificate is generated.

That is why a software company, a design studio or a consultancy selling abroad ends up caring about invoice hygiene more than an exporter of goods does. Their invoice is not a commercial courtesy that accompanies a customs document. It is the only document in the chain, and every later reference to that export is a reference to it.

The classification code matters here for the same reason. A service export filing carries the SAC code for what was supplied, and the invoice is usually the one place it is already written down.

Why a payment often does not match the invoice

A remittance that does not equal the invoice total is normal, and the reasons are worth naming because each one is handled differently.

A part payment against a large invoice arrives as a share of it, and the rest arrives later, so one invoice ends up mapped against two remittances. A discount agreed after the invoice was raised makes the payment smaller than the document by an amount that is real and documented, which is what the discount field exists for. An agent's commission deducted before the money leaves the buyer's side produces the same shape and is a different field. And a payment can simply arrive net of charges deducted along the way between the buyer's bank and yours.

Every one of those is a difference somebody has to explain when the certificate is filed, and every one of them is easier to explain when the invoice figures were read off the document rather than remembered.

From the export invoice to the eBRC

An eBRC is the Electronic Bank Realisation Certificate that records an export payment arriving and being realised in India. Since the DGFT revamped the system it is self-certified: your bank reports the inward remittance, and you certify which export it paid for. Certifying that means naming the export document, its date, the currency and the value, which for a service export is precisely the invoice this tool just read.

The tool stops at reading. Filing is the next step, and the eBRC exporter app is where it happens: connect a DGFT account once, and inward remittances arrive on their own to be mapped against documents like this one. It is free at any volume, with no certificate limit and no paid tier for exporters. If you are putting documents through software rather than by hand, the same reader is available over the eBRC API.

Two related things are worth a look while you are here: the shipping bill extractor, which does the same job for the customs document a goods export carries, and the RBI purpose code lookup, for the code that arrives on the remittance this invoice is going to be paid by.

Questions people ask about reading an export invoice

Yes. Ten invoices a day, with no sign-up, no account and no card. The ten are counted per internet connection rather than per person, because there is no account to count against, so an office sharing one connection shares them, and the count resets at midnight IST. The limit exists so the tool stays free for everyone rather than becoming somebody's batch process. The eBRC exporter app reads invoices with no limit at all and is also free, at any volume.

It is read, the fields come back, and the file is kept. We store it so the extractor can be improved against the real invoices people upload, which is how the parsers get better at the layouts exporters actually issue. There is no account, no email box and no cookie set for this tool. The only thing counted is how many invoices have come from your internet connection today, and that count sits against a one-way fingerprint of your connection, holding no part of your document and no address anybody could read back.

Upload the PDF here and download the result as CSV, which opens directly in Excel or Google Sheets. There are two sheets: the fields, which are the invoice number, date, currency, totals, parties and terms with the key each value was read from, and the line items, which are one row per line with the description, quantity, rate and amount. The whole parsed document is also available as JSON.

The PDF your invoicing software generated, downloaded as a file. It carries a text layer, which is what makes every field readable exactly as printed. A scan of a printed invoice or a photograph taken on a phone has no text layer and is refused rather than guessed at, because a guess about an invoice value is worse than a clear refusal. Invoices from accounting software, from a billing platform, or exported from a spreadsheet all carry that text layer.

Everything the invoice prints, in two groups. The first is the set a realisation filing asks for: the invoice number, the invoice date, the currency, the invoice total, the subtotal and tax, and the freight, insurance, discount and commission that may be deducted before the realisable value. The second is the rest of the trade: the exporter with GSTIN and IEC, the buyer, the country of destination, the delivery and payment terms, the classification code, the purchase order reference and the bank details the invoice asks to be paid into. Every line item comes back as its own row.

It means the figures on the invoice do not reconcile with each other. Three sums are tested: quantity times rate against the amount on each line, the line amounts against the subtotal, and the subtotal plus tax and charges less discount against the stated total. A difference of a hundredth is rounding and is ignored. Anything larger is worth a look before the invoice goes to a buyer or the value goes into a filing, because an invoice that does not agree with itself is one a buyer can query and hold payment against.

Because an eBRC is self-certified against a specific export, and for a service export the invoice is the export document. There is no shipping bill for a service, so the invoice number, its date, the currency and the invoice value are what the inward remittance is mapped against when the certificate is generated. For a goods export the invoice sits beside the shipping bill and has to agree with it, which is why the numbers on both are worth reading rather than retyping.

It has to match what the buyer quotes when they pay and what your bank reports on the inward remittance. A realisation filing carries the invoice number in a twenty character field, so an invoice number longer than twenty characters gets shortened somewhere, and once it is shortened the match to the remittance stops being automatic. The tool says so when it sees one, which is a cheaper moment to find out than the day the payment arrives.

Yes. The reader on this page is available as an API for platforms and enterprises reading invoices in volume from their own systems. It is documented alongside the eBRC API and takes its own key. Nothing about it changes the eBRC exporter app, which is free at any volume with no certificate limit.

Get started

Reading the invoice is a minute. The certificate is the point.

The eBRC exporter app is free at any volume. No certificate limit, no card required.