ApexAutomation
Apex Automation

Apex Automation free tools

Bulk Invoice Generator

Every invoice checked before it leaves, not after it bounces

Making one invoice is easy and every tool does it. The work is in the thirty you send at the end of the month, where one is reverse charged and the next is not, where a client's VAT number has a digit missing, and where a number got used twice. Drop the spreadsheet you already bill from. Each row is read, each invoice is worked out on its own, and anything that would come back to you is named before you send it.

  • Free to use
  • No account needed
  • Nothing uploaded
  • No row limit

Nothing to hand?

Drop a spreadsheet of billing rows here

or

One row per line on the invoice. Rows that share an invoice number become one invoice.

What this page will read

  • .csv, .tsv or .xlsxSemicolon, tab and pipe separated too. In a workbook the first sheet holding rows is read, so a cover page in front of it is stepped over.
  • Any column names, in any languageRechnungsnummer, montant, 数量, Importo, Kwota and plain Amount all land in the right place. Where a name is unfamiliar the column is read by the shape of what is under it.
  • One row per line, grouped by invoice numberTwo rows carrying INV-0041 become one invoice with two lines. A row with no number still becomes an invoice and is given one.
  • Any number of rowsThere is no cap and no sign up. The work happens on your own machine, so the limit is your machine.
  • Amounts written the way your country writes them1.234,56 and 1,234.56 and 1 234,56 all read correctly, and where a number genuinely has two readings the page says so instead of picking one.
  • Any country, mixed in one fileRates and rules for 87 countries, and every one of them can appear in the same batch, each invoice worked out on its own.
  • Any currencyThe yen with no decimal place and the dinar with three are both handled, because rounding to two places is a bug in both.
  • Any numeral systemArabic, Devanagari, Bengali, Thai, Khmer and more than fifty others, plus Chinese numbers written out in words. The amount is read, not refused.
  • Any encodingUTF-8, UTF-16, Windows-1252, with or without a byte order mark. A file that is not UTF-8 is read correctly and named, so an accented client name does not arrive broken.
  • Columns it does not needInternal references, project codes, anything else. They are read past, left alone and not changed.

What it works out for itself. The tax treatment, the wording, the tax category for the e-invoice, and the invoice number where a row has none. Everything it worked out is shown with the reason it used, so you can disagree with it in one place rather than hunting for it.

Your details, which go on every invoice

The same amount, five different invoices

Take nine hundred euro of consulting work. If the client is in your own country you charge your own rate and the invoice is unremarkable. If the client is a VAT registered business one country over, you charge nothing and the invoice has to say why, citing Article 196, with the client's number on it as the evidence that the rule applies. If that same client never sent you their number, the reverse charge does not apply at all and you should be charging VAT. If they are a private person rather than a business, you charge your own rate again. And if they are outside the European Union entirely, the supply falls outside the scope and the invoice says so differently.

Five invoices, one amount, and the difference between them is not the arithmetic. It is a sentence at the bottom of the page and a tax category in the file underneath.

Which is why a single tax box on a form is the wrong shape for this job.

Most free generators give you one. You set it once and it applies to the whole invoice, and to the next one, and to the thirty after that. The moment your client list crosses a border the box is wrong for some of them and there is nothing on the page to tell you which. Here the treatment is worked out per invoice from what the row actually says, and the reason is printed next to the result in words you can check.

What is claimed, and what is not. The page applies the general rules for cross-border services and goods, the United Kingdom construction reverse charge, and the Indian place of supply split. Property, events, passenger transport, margin schemes, second hand goods and digital services sold to consumers all have their own rules that this page does not try to apply, and it says which rule it used on every invoice so you can see when none of them is the one you need.

The United Kingdom one that everyone gets half right

The domestic reverse charge for construction has applied since March 2021, and the invoice it produces is not a normal invoice with the VAT line deleted. The VAT still has to appear. You show the rate, and the amount the customer will have to account for, and then you leave that amount out of what you are asking to be paid.

Every free generator that handles the reverse charge at all handles the European one, which works the other way: the VAT is simply absent. Apply that shape to a construction invoice and you have left out something the regulations ask for. This page keeps them apart. A United Kingdom construction invoice carries the section 55A wording, the rate, and the amount in figures, with a line saying it is not in the total, and the total agrees.

There is a second trap in the same rule. The reverse charge stops applying when the customer is an end user, but only if they have told you so in writing. Silence is not a declaration. So the default here is that the reverse charge applies, and charging VAT instead is something you turn on for a customer who has actually sent you the declaration, rather than something that happens because nobody filled in a field.

India, where one rate becomes two columns

An Indian invoice does not carry a single tax figure. The same eighteen percent splits into nine percent of central tax and nine percent of state tax when the supply stays inside one state, and becomes eighteen percent of integrated tax when it crosses into another. Which of those applies is decided by the place of supply, and the place of supply is usually readable from the first two digits of the customer's own GSTIN.

So this page reads it from there, splits the tax into the right heads, and puts the place of supply on the invoice with the state named, which Rule 46 asks for. When the split is an odd number of paise the halves are not both rounded, because two rounded halves do not add back to the whole. One half takes the extra unit and the two columns sum to the figure in the total.

The GSTIN itself is checked rather than accepted. Its last character is a check character over the first fourteen, computed with Luhn in base thirty six, and a single mistyped digit fails it. The state code is checked against the published list, and the fixed Z in the fourteenth position is required, because a number that passes the eye and fails the portal is worse than one that fails both.

The invoice number, which nothing else checks

Article 226 asks for a sequential number that identifies the invoice on its own. Rule 46 asks for a consecutive serial number of no more than sixteen characters, unique within the financial year. Both are short sentences and both are broken constantly, because a number is checked by the person typing it and by nothing else in the chain.

A batch is where the breakage becomes visible. Two invoices carrying the same number is the serious one, and it happens whenever two systems both think they are allocating the next one. A number missing from the middle of a series is not automatically wrong, because that invoice may exist somewhere else, but it is always worth knowing about. And the quiet one is padding: INV-7 and INV-0007 read as the same number to a person and as two different numbers to anything that sorts them.

All three are reported across the whole batch, with the positions, before anything is downloaded.

Where the cent goes, and why there are two answers

Add the tax on each line and then total it, and you get one number. Total the lines first and work the tax out once, and you sometimes get a different number. Neither is a mistake. They are two methods and they disagree by a cent or two on invoices with several lines, which is exactly the kind of difference that a client's accounts payable system rejects an invoice over.

The European standard checks the second method: it compares each VAT category's tax amount against that category's taxable amount times the rate. So that is the method this page uses. It also works the first one out, and where the two differ it says so, with the amount, instead of quietly picking one and leaving you to discover the difference in a reconciliation.

Underneath, no amount is ever held as a decimal fraction. Every figure is an integer count of the currency's smallest unit, which is why a hundred lines of ten cents come to exactly ten euro here and not to nine ninety nine with a tail of nines. The yen, which has no smaller unit, and the dinar, which has three places rather than two, are both read and written at their own precision.

An e-invoice, and a second opinion about it

Belgium has required structured business to business e-invoicing since January 2026. Poland's system took in its largest taxpayers in February and everybody else in April. France's mandate landed on the first of September, and from that date every business there has to be able to receive one. All of them are built on the same European semantic standard, and the document underneath is either UBL or its cross industry equivalent.

So every invoice here comes with that document. What makes it worth having is the second half: the file is then read back and checked against the standard's own business rules, the ones that compare the lines to the totals and insist that a category charging no VAT gives the reason it is not charging any.

Why the checker is a separate thing. It would be easy, and useless, to check the invoice against the same code that built it. Both halves would agree, including about a mistake. So the checker shares nothing with the builder: it reads only the finished XML as text, it works the amounts out with its own arithmetic, and the rules in it were written from the published rule list rather than from the code that writes the file. When a deliberate fault is put into the builder, the checker is what notices.

Checking a tax number without asking anybody

A VAT number is not a random string. Most countries build a check digit into it, so a transposed pair or a mistyped digit can be caught by arithmetic alone, with no network call and nothing leaving the page. Eight schemes here are checked that way: the United Kingdom in both of its series, Ireland, Germany, France, Belgium, Italy, the Netherlands in both its old and its post-2020 form, and the Indian GSTIN.

The rest are checked for shape, and the page says that is what it did. Several countries publish no check digit algorithm at all, and a tool that reports all twenty seven member states as validated is reporting a regular expression as arithmetic. The difference matters most on a reverse charge, where the customer's number is the evidence that you were right not to charge VAT.

What none of this proves is that the number belongs to a registered business today. That needs a call to the European Commission's VIES service or to HMRC, which is a different kind of check and a different kind of page. This one tells you the number is arithmetically sound and leaves the registry question where it belongs.

What has actually been tested

Every figure here is a test run that has to pass before anything reaches this page. If one fails, nothing ships. A number on a page that nothing checks goes stale, so a test reads this page, pulls out every figure in it, and compares each one with the code behind it.

448automated checks, all passing
14suites, each runnable on its own
6,000pieces of junk, every one answered or refused with a reason
31deliberate faults, every one caught
49rules of the European e-invoice standard, checked on every invoice
0bytes uploaded
The checker and the builder share nothing The file that writes the e-invoice and the file that checks it have no code in common. The checker reads the finished XML as text, works the amounts out with its own arithmetic, and applies rules written from the published list. A fault put into the builder on purpose is caught by the checker, which is the only way to know the check is worth anything.
Every amount in, exactly once out The rule that makes this tool checkable: every amount read from the file appears in exactly one invoice, in exactly one tax category, and the categories add to the total. It runs on every batch, including yours, and the result is on the page above the invoices rather than buried under them.
Every combination, not just the one in the example Nine tax categories against six kinds of border against four currencies, each built and then checked against the standard. A hundred thousand rows in one file. A single invoice with five thousand lines. Fifty separate number series in one batch. A one character description and a four thousand character one. The limits here are the machine's, and the tests push until the machine is what gives way.
Six thousand pieces of junk Half-written rows, amounts that are sentences, dates from the wrong century, control characters, text that is not a spreadsheet at all. Every one has to come back with either an invoice or an error a person can act on, and that hunt is where several of the quieter faults in this page were found.

Properties you can hold it to

Questions people ask first

How does it know whether to charge VAT or use the reverse charge?

From the supply itself rather than from a switch you set once. It looks at where you are, where the customer is, whether the customer gave a tax number, whether they are a business, and what kind of supply it is. Services to a VAT registered business in another member state come out as a reverse charge under Article 196. Goods moving to one come out as an intra-community supply under Article 138. Construction work between two VAT registered businesses in the United Kingdom comes out under section 55A. Everything else is charged at your own rate, and the page tells you in a sentence which rule it used and why.

Is my billing data sent anywhere?

No. The file is read inside this browser tab and the invoices are built there too. There is no upload endpoint and no server to receive anything. You can disconnect after the page has loaded and carry on working, which a test does on every run. Nothing is stored either, so closing the tab leaves nothing behind, which matters when the file is a list of every client you have and what you charge them.

What does it check an invoice against?

Two separate things. The mandatory particulars of the jurisdiction it belongs to: Article 226 of the VAT Directive for an EU invoice, regulation 14 for a United Kingdom one, Rule 46 of the CGST Rules for an Indian one. And then the e-invoice XML is checked against the European standard's own business rules, the BR and BR-CO series, which cover whether the lines add up to the totals and whether a zero rated category carries the reason the standard requires.

Why does it check the invoice numbers?

Because the law asks for a sequential number that identifies the invoice on its own, and nothing else checks it. Across a batch this page finds duplicates, which are the serious one, numbers missing from the middle of a series, blanks, and the case where the same number appears with different padding so that it reads as one number to a person and two to a computer. In India it also checks the sixteen character limit that Rule 46(b) sets.

Can it produce a real e-invoice for the French or Polish mandates?

It produces the EN 16931 UBL 2.1 document those mandates are built on, with the VAT categories, the exemption reasons and the totals the standard requires, and it checks that document against the standard's own rules before handing it to you. Getting it onto a network such as Peppol or into KSeF is a separate step through a provider, because those are authenticated connections to a government system rather than a file format.

My spreadsheet has the columns in a different order and a different language.

That is the normal case and it is handled. Column names are read in several languages, and where a name is one this page has not seen, the column is read by the shape of what is under it: a column of two letter codes is a country, a column of amounts with a currency symbol is money, a column of dates is a date. The page shows you what it decided for every column, including the ones it did not use, so you can see it got your file right before you download anything.

What happens to a row with no invoice number?

It still becomes an invoice. Rows with no number are grouped by customer and date, so a day's work for one client arrives as one invoice rather than five, and then it is given a number in a series you can set. The invoice is marked as having been numbered here rather than in your file, because a number you did not choose is something you should see rather than discover later in your own sequence.

Why does the total sometimes differ by a cent from my accounting system?

Because your system probably rounds the tax on each line and then adds those up, and the European standard checks the other method: the taxable amount for each rate is totalled first and the tax worked out once. On an invoice with several lines the two disagree by a cent or two. This page uses the method the standard checks, works the other one out as well, and tells you the difference whenever there is one, so you can see where the cent went rather than hunting for it in a reconciliation.

Tell us what would make this better

An invoice this page treats wrongly is the most useful thing anyone can send us. Take the client names out first, the shape is enough. toolssupport@apexautomationteam.com

  • A country whose rules are not applied here yet
  • A column heading your export uses that was not recognised
  • A rate that has changed since 2026-10-21
  • A version of this wired into your own billing system
  • Something else altogether, built to your spec

Email our team See what we build

This page is a tool, not tax advice. Where a rule is unusual, your accountant is the one to ask.