---
title: "How to automate invoicing without duplicates | JustAutomate"
description: "When the invoice should be created, which fields to check before the run, and how not to issue it twice. Numbering, credit notes, currency, manual queue."
url: "https://justautomate.ai/en/guides/how-to-automate-invoicing/"
lang: en
---

Finance, reporting and data

# How do you automate invoicing? without issuing the same document twice

An automation issues an invoice from whatever it is given, and it never asks whether that makes sense. This guide is about the traps: the event that creates the document, the fields checked before the run, duplicates, numbering, credit notes, e-invoicing and the exchange rate. At the end, five steps and the list of things that stay with a person.

8 minutes read

- 10 to 30 minuteswhat issuing one invoice by hand costs today: retyping the buyer details, the line items and the amounts, then sending it. Our own estimates from quoting
- 6 stagesthat is how many points the billing cycle has, from order to posting; an automation takes each one on separately
- 4 fieldsVAT number, address, VAT rate and payment terms; without the full set the automation issues a document that needs a credit note
- 30 and 90 dayswhen we read the result after go-live, against the numbers measured before the first workflow went live

Short answer

## How do you automate invoicing so the documents still add up?

Start with one sentence: which event creates the invoice. A paid order, a deal moved to closed, a signed acceptance note, a date on a subscription schedule. As long as that event is „when the rep remembers”, no tool will fix it.

Then the data. VAT number, address, VAT rate and payment terms have to be complete in the source record before the workflow runs. Validation is its own step: a missing field holds the document in a queue, a missing validation turns it into a credit note.

Last, decide what the automation does not do. The invoicing system assigns the number, a credit note that changes an amount waits for approval, anything outside the flow goes to a manual queue. The rest of the path runs without a person, and the full cycle is on the [invoice automation](https://justautomate.ai/en/services/invoice-automation/) page.

## When exactly should the invoice be created?

You settle the trigger before you pick a tool. Not „after the sale”, but a specific state in a specific system: the deal stage on closed, the order status on paid, an accepted acceptance note, the fifth of the month in the contract register. A state like that can be read through an interface and checked in a log.

A bad trigger fires twice or never, because somebody rolled the deal stage back and set it again. A good one carries extra conditions: amount greater than zero, buyer with a VAT number, no invoice yet for this order.

- A won deal in the CRM (HubSpot, Pipedrive, Salesforce), with a condition on the amount and on complete buyer details
- A paid order in the shop or in the order manager, confirmed by the payment gateway, not the order being placed
- An accepted acceptance note, where you bill by milestone
- A date on the subscription schedule, calculated from the contract register, not from a list somebody ticks off
- An approved timesheet, where you bill your team's hours

**Note.** „When the rep remembers” is not a trigger, it is a missing process. So the first output of a workshop is often not a workflow but a decision that the invoice is created from the order status.

## Which fields have to be complete before the automation runs?

An automation does not check whether something makes sense, only whether the field is there. If the VAT number is missing from the record, it issues an invoice without one and asks nobody. Validation is a separate step in the workflow, and it is what decides whether the document moves on or goes to the manual queue.

Below is the minimum we check on every implementation. The third column matters more than the first.

| Field                      | Where the automation takes it from                                       | What happens when it is missing                                                              |
| -------------------------- | ------------------------------------------------------------------------ | -------------------------------------------------------------------------------------------- |
| VAT number and legal name  | the company record in the CRM, the order data, a public VAT register     | an invoice with no VAT number or with a typo, corrected later on the buyer's side            |
| Address and country        | the counterparty card, the shipping details on the order                 | the wrong country is the wrong rate on a cross-border sale, and a credit note after the fact |
| VAT rate on the line item  | the product or service record, not what a rep typed in                   | a rate copied from the previous invoice by mistake, and a gap in the VAT ledger              |
| Payment method and terms   | the terms stored on the customer, not in an email thread                 | the default term instead of the agreed one, so chasing starts on the wrong day               |
| Currency and exchange rate | the currency from the contract, the rate from one agreed source and date | everyone works it out their own way and the differences surface at quarter end               |
| Order or deal reference    | the source system, written onto the document as well                     | there is no way to check whether an invoice for this order already exists                    |

We run the same set before go-live on production, against your own documents from the last month. A missing field holds the document with a note saying what is missing.

## How do you avoid issuing two invoices for one order?

This is the most common failure in automated invoicing and the most expensive one, because you fix it with a credit note rather than a setting. A duplicate appears when the workflow runs a second time for the same event: somebody rolled a deal stage back and forward, the integration replayed the event after a network error, somebody clicked „run again”.

There is one cure. Before it issues anything, the workflow asks whether a document for this identifier already exists. The identifier is the order or deal number, never the customer name and never the amount. The whole scenario is written out in [automatic invoicing from CRM](https://justautomate.ai/en/automations/automatic-invoicing-from-crm/).

- One identifier on the invoice: the order or deal number, in a document field, not in the description
- A check before issuing, asking whether a document with that identifier already exists
- A return marker: the invoice number goes back to the CRM and blocks the next run
- A one-way condition on the stage change, so rolling it back is not a new sale
- An error queue instead of a silent retry, carrying the error text and the order number

**Note.** On production a duplicate usually comes from a person re-running the scenario after a fix, not from a tool failing. The block belongs in the data, not in the discipline of whoever is clicking.

## Who assigns the invoice number, and why not your script?

An invoice number is not a piece of text. The invoicing system is responsible for it: it keeps the series unbroken, keeps the dates in order, and makes sure two documents issued at the same second do not get the same number. A script that builds numbers off a counter in a spreadsheet will sooner or later produce a duplicate or a gap in the series.

The workflow's job is to point at a series, not to calculate a number. The series comes from a rule agreed in the workshop: one for domestic sales, another for proformas, credit notes and cross-border sales. Xero, QuickBooks, sevDesk and Fakturownia all keep their series themselves, and one such wiring is shown on the [Fakturownia integration](https://justautomate.ai/en/integrations/fakturownia/) page.

- The invoicing system assigns the number, the workflow receives it and writes it back onto the order
- The series comes from a workshop rule, by document type and sales channel
- A back-dated document, or one outside the series, gets flagged to accounting instead of issued
- The reference returned by the e-invoicing channel goes back to the CRM next to your own number, because payments and corrections are reconciled against it

## What about e-invoicing, payment terms and currency?

Three things to settle before the build, because each one you skip ends in a credit note. E-invoicing, because the invoice now has a fixed structure and a fixed delivery path. The payment term, because chasing is counted from it. The exchange rate, because without a rule everyone works it out differently.

Countries across the EU are phasing in mandatory e-invoicing on their own timetables, and the direction is the same everywhere: the invoice stops being a PDF and becomes a structured document that one system sends and another receives, with a confirmation coming back. Check the timetable and the format for the country you invoice in, and settle who owns that step before the workflow is designed.

| Rule                             | What you settle before the build                                                                         | Who decides                                     |
| -------------------------------- | -------------------------------------------------------------------------------------------------------- | ----------------------------------------------- |
| Sending as a structured document | whether the invoicing system sends it or the workflow does, and what happens to a rejected document      | accounting together with your invoicing vendor  |
| Reference and status coming back | where the confirmation is written and after how long no answer becomes an alert                          | your side, while the workflow is being designed |
| Sale date versus issue date      | which date the payment term is counted from and where the automation reads it                            | accounting                                      |
| Payment terms                    | the default value and the per-customer exceptions, stored on the customer record                         | sales together with finance                     |
| Exchange rate                    | the source of the rate, the date, the conversion used for VAT and how the exchange difference is counted | accounting, the automation only executes        |

Each of these rules fits in one sentence, and none of them can be left unsaid. A rule nobody wrote down still ends up in the configuration: it gets written by whoever builds the workflow.

## What always stays with a person?

Automation does not mean nobody looks at the documents any more. It means a person looks only at the ones that need a decision. The list of those cases is written in the workshop, not discovered after go-live.

We are most careful with corrections. A technical credit note, from a return that was accepted, can be created automatically and tied to the original invoice, because the basis is unambiguous. A credit note that changes the amount after a commercial conversation waits for approval. Some corrections are the buyer's to issue rather than yours, so the automation only flags those.

- A credit note changing an amount on the basis of an agreement that exists nowhere in the systems
- The first invoice for a new counterparty, before the VAT number and VAT status are verified
- A back-dated document, one outside the series, or one issued after the period is closed
- A sale to a customer over their credit limit or with money already overdue
- A document rejected by the e-invoicing channel, together with the error text and the order number

**Note.** A manual queue needs one property: next to every document you can see why it landed there. Without that it turns into a second inbox that nobody opens after a month.

## How to sort out invoicing in five steps

The first three steps happen without a tool. Process first, tools second: only step four is about what you build the workflow in. The reverse order gives you a fast automation issuing bad documents.

1. ### Measure how long the document takes
Count in days: from sale to invoice, from invoice to payment, from payment to it being reconciled. Measure on real documents, because declarations understate this.
2. ### Settle one trigger event
Write down in one sentence which state in which system creates the invoice. Add the conditions: minimum amount, complete buyer, no invoice yet for this order.
3. ### Write down the rules and the exceptions
Numbering series, payment terms, the source of the exchange rate, the rules for corrections and the list of documents the automation never issues on its own. This document holds up without us and without a tool.
4. ### Build the workflow and test the hard cases
n8n, Make, Zapier or a direct API integration, wired into your invoicing system and your CRM. Test credit notes, foreign currency invoices, buyers with no VAT number and a repeated event.
5. ### Run it alongside the current way and read it at 30 and 90 days
The workflow runs in parallel with manual issuing. At 30 days you fix whatever is out of line, at 90 you compare against the days you counted in step one.

Common mistakes

## Six mistakes that make the automation issue bad documents

- The trigger is a rep's memory, not a state in a system
The invoice goes out on Wednesday for a Friday sale, so the payment term starts five days late. The automation has nothing to listen to, because nothing changes in the data.
- No validation of the data before issuing
The document reaches the buyer with no VAT number or with the wrong VAT rate. The cost is a credit note, accounting time and a conversation with the client.
- No block on a second run
Two invoices for one order, and a credit note to unpick it. The customer balance stays wrong until somebody notices.
- The invoice number built by a script off a counter in a spreadsheet
A gap in the series, or two documents carrying the same number. Cleaning that up afterwards is work for accounting, not for a workflow.
- Credit notes issued automatically with no approval
The amount changes with no human decision, and the basis for the correction exists only in a conversation with the client. In an audit there is nothing to justify it with.
- The exchange rate worked out separately in every place
The same sale carries a different amount on the invoice, in the CRM and in the ledger. The differences surface at quarter end and get straightened out by hand.

Checklist

## Checklist before you run the automation on production

If any line is a no, the automation will issue a document somebody has to fix later.

- The trigger written down in one sentence, as a state in a specific system
- Extra conditions: minimum amount, complete buyer, no invoice yet for the order
- VAT number, address, VAT rate and payment terms checked before issuing
- The order reference on the invoice, the invoice number written back onto the order
- The number and the series assigned by the invoicing system, the workflow only receives them
- The exchange rate rule and the payment term rule written down: one source, one date
- A list of documents the automation never issues on its own, each with a reason
- Sending as a structured document owned by one side, with a path for a rejected document

Sources

## Sources

1. [n8n documentation: triggers, error handling and re-running executions](https://docs.n8n.io/)
2. [Make help centre: scenarios, triggers and run history](https://www.make.com/en/help)
3. [HubSpot developer documentation: deal stage changes and webhooks as an invoicing trigger](https://developers.hubspot.com/)
4. [JustAutomate, invoice automation: the six stages of the billing cycle](https://justautomate.ai/en/services/invoice-automation/)

Let us walk your billing cycle

## Before you build the automation, count the days

The free consultation takes 30 minutes. We walk your path from sale to payment and look for the point where an automation would issue the wrong document. The process workshop costs EUR 3,500 net per week and ends with the rules written down: trigger, series, terms, exchange rate and the list of exceptions. You write directly to Paweł.

[Book a free consultation](https://justautomate.ai/en/contact/)

## Frequently asked questions

How do you automate invoice issuing?

In three moves: name the event in a system that creates the document, describe the data required before issuing, and list the cases the automation does not handle. Only then do you build the workflow in n8n, Make, Zapier or through an API, and wire it into your invoicing system and your CRM.

When should the automation issue an invoice?

When a specific state changes in a system: the order gets the paid status, the deal moves to closed, the acceptance note is approved, or a date comes up on the subscription schedule. Add the conditions on top: an amount greater than zero and no invoice yet for this order.

How do you avoid a duplicate invoice for the same order?

Write the source identifier onto the invoice, meaning the order or deal number, and check before issuing whether a document with that number already exists. Write the invoice number back onto the record in the CRM: that is what blocks the next run.

Can the automation assign invoice numbers?

The invoicing system assigns the number, not the workflow. It is the one keeping the series unbroken and making sure two documents issued in the same second do not get the same number. The workflow picks the series and writes the finished number back onto the order.

Can credit notes be issued automatically?

Only technical ones with an unambiguous basis, for example from a return that was accepted; that credit note is created on its own and tied to the original invoice. One that changes the amount after a commercial conversation waits for approval from whoever owns invoicing.

Does automated invoicing handle e-invoicing?

Yes, it is one stage of the cycle. You settle whether the invoicing system or the workflow sends the structured document, and what happens to one that gets rejected. Mandatory e-invoicing is being phased in across EU countries on different timetables, so check the format and the date for the country you invoice in.

How does the automation work out the exchange rate on an invoice?

By a rule written down before the build: one source of the rate, one date, one conversion for VAT and an agreed way of counting the exchange difference on payment. We store the rate and the date next to the document, so anyone can reconstruct where the amount came from.

## Related

- [Invoice automation](https://justautomate.ai/en/services/invoice-automation/)
- [Automatic invoicing from CRM](https://justautomate.ai/en/automations/automatic-invoicing-from-crm/)
- [Automatic payment reminders](https://justautomate.ai/en/automations/automatic-payment-reminders/)
- [Fakturownia integration](https://justautomate.ai/en/integrations/fakturownia/)
- [Automation ROI](https://justautomate.ai/en/guides/automation-roi/)
- [Process workshop](https://justautomate.ai/en/services/process-workshop/)

---

**JustAutomate** · contact: contact@justautomate.ai · form: https://justautomate.ai/en/contact/