Skip to main content
You manage software that creates or receives invoices. This can be a billing tool, a spend management platform, an ERP, or any SaaS that handles commercial transactions. Your end-users want to book those invoices in the accounting software. Automatic booking is what makes this integration valuable. Without it, someone must re-enter each invoice manually in the accounting software. That work is slow and error-prone. With it, your end-users’ books stay up to date automatically, with no manual data entry. This article explains what “booking an invoice in the accounting software” means. It also covers what your end-users must configure first, and what happens at each step. You do not need an accounting background to build this integration. The people who own the books make the accounting decisions.

​
Invoice types

Your software can push four types of invoices to the accounting software:

​
What happens in the accounting software

Accounting systems handle invoices in two ways. Some have a dedicated invoice object. You create the invoice through the API, and the system generates the journal entry automatically. Others work with journal entries only. You create the entry directly from the invoice data. Either way, Chift handles the difference. You send the same invoice payload, and Chift produces the correct result for each accounting system. A journal entry is a structured double-entry record. It captures the revenue or expense, the VAT, and the receivable or payable balance. The breakdown below shows why you must configure a few settings first. The account numbers below follow the Belgian PCMN chart of accounts; the exact codes differ by country.

​
Sales invoice example

A customer invoice of €121 (€100 net + 21% VAT):

​
Purchase invoice example

A supplier invoice of €242 (€200 net + 21% VAT): The same logic applies in reverse for credit notes and refunds. This accounting logic is why you must configure a few settings before you can book invoices. The accounting software needs three things: which journal to use, which ledger account to use for each line, and which VAT code applies. Those settings determine how the accounting software records what was sold or bought: the revenue or expense account and the VAT code. The journal entry also needs to record who owes or is owed. That is the partner. A partner is a customer (for sales) or a supplier (for purchases). In the examples above, the partner appears on the receivable line (customer) or the payable line (supplier). The partner side is largely automatic. Once the accounting software knows which partner an invoice belongs to, it books the amount against that partner’s balance. The next section covers this.

​
Partner handling

A partner must exist in the accounting software before you can book its invoices. Build the link once, then reuse it:
  1. Fetch the customers and suppliers already present in the accounting software.
  2. Match them against your own customer and supplier list, usually on VAT number, company registration number (for example, SIRET in France or KVK in the Netherlands), or name.
  3. Store each partner’s id from the accounting software alongside your own record.
  4. Reuse that stored id on every invoice you send for that partner. This id is enough: the accounting software resolves the correct partner balance automatically.
If one of your partners has no match, create the partner in the accounting software through the API before booking the invoice. Use the data you already hold: name, VAT number, and addresses.
If someone deletes a partner from the accounting software after setup, invoice creation fails. The partner must exist again before you can book its invoices.
Who configures what. Your end-user, or their accountant, makes the accounting choices: which account, journal, and VAT code each invoice uses. They know their own books; you never make these choices. They make them in a mapping screen at setup. You build this screen with the Unified API, or Chift provides it with a Sync (see What you build). This article describes those choices so you can support that setup, not because you make them yourself.

​
Required mappings

Before you can synchronize invoices, your end-users must configure a set of mappings. A mapping links a concept in your software to the matching object in their accounting software. Your end-user, or their accountant, configures the mappings once, at connection setup.

​
Journals

An accounting journal is a dedicated logbook for a category of transactions. Every entry belongs to one journal. Your end-users select:
  • Sales journal — for customer invoices
  • Purchase journal — for supplier invoices
  • Sales refund journal — for customer refunds (credit notes) (may be the same as the sales journal)
  • Purchase refund journal — for supplier refunds (credit memos) (may be the same as the purchase journal)
The available journals come from the accounting software. Your end-users select from what their accountant already configured.

​
VAT and tax codes

Accounting systems do not record a VAT percentage directly. Instead, they use an internal VAT code. This code represents a rate and how to treat it. So you must link each VAT rate in your invoices (for example 21%, 6%, or 0%) to the matching VAT code in the accounting software. The accounting software treats the same rate differently by direction. On a sale, it collects the VAT (output VAT). On a purchase, the VAT is deductible (input VAT). The system uses a different code for each. So your end-users map each rate twice (once to its sales code, once to its purchase code) when they handle both sales and purchase invoices.

​
Revenue and expense ledger accounts

Every invoice line must state where its amount goes in the books: its ledger account. For a sale, this is a revenue account (the income earned). For a purchase, it is an expense account (the cost incurred). Each line has its own account. So when several revenue or expense accounts are in use, each line states which one it uses. Your end-user chooses how much detail they want in their books:
  • A single account each. All sales go to one revenue account, and all purchases go to one expense account. This is the simplest setup: one default revenue account and one default expense account for every line. For many integrations, this is enough.
  • Split by type. Your end-user may want their books, and their profit-and-loss view, to separate categories, for example subscription revenue from one-off sales, or software costs from travel. In that case, they map each of your product or expense categories to its own account. Your software then sends the matching account on each line. Any line without a specific account uses the default.

​
What you build

Your end-user always makes the accounting choices above: the journal, the VAT code for each rate, the revenue or expense account, and the partner for each invoice. These are decisions about their own books, not yours. You build the integration around those choices. What you build depends on how you connect to Chift. With the Unified API, you build it yourself:
  • a mapping screen where your end-user selects their journals, VAT codes, and accounts (you fetch the options from their accounting software and present them);
  • storage that keeps each partner’s accounting id and reuses it on their invoices;
  • send logic that puts the right account and VAT code on each line and attaches the PDF.
With a Sync, Chift builds it for you. The mapping screen and the booking run on Chift’s side. Your end-user makes the same choices through Chift’s interface. You build neither the screen nor the booking logic.