Documentation/ ERP integrations/ SAP Business One
Supplier invoices straight into SAP Business One
Dijit.app reads a supplier invoice, a PDF or a scan, and creates it as a purchase invoice in SAP Business One: the right item or account line, the right tax group, the Spanish immediate VAT reporting fields filled in and the original document attached. All over the Service Layer your system already exposes: nothing to install inside SAP.
Several companies at once
One integration serves every company database you run, each with its own user, its own defaults and its own data.
Item lines or expense lines
Items with a warehouse and a batch, or lines straight to a nominal account. Often both on the same invoice.
VAT reporting fields filled in
The user fields your SAP partner set up for immediate VAT reporting are filled in on every document.
It does not guess
An invoice it cannot classify with certainty fails with a specific reason. It never invents a tax value.
On this page
What it does
From a PDF on the desk to a posted document
Finding the supplier by tax number
Tax numbers arrive off documents in a thousand shapes: with a country prefix or without, with spaces, with hyphens, in capitals or in lower case. Every plausible form is tried against the business partner master until a match is found. Blocked suppliers are excluded, and the supplier's currency and payment terms come back with the match.
Lines that look like yours
A line can carry an item code with its warehouse, batch, unit of measure and discount, or go straight to an expense account, or both at once: an item and an account chosen on purpose. Lines with neither fall to whichever expense account you nominate.
The right tax group, on every line
Each line is classified by the supplier's country, the rate shown on the document, whether it is goods or a service and the nature of the invoice, then translated into your tax group, agreed with your finance team before you go live.
Invoices and credit notes
A credit note automatically becomes a purchase credit note, by the same path and with the same checks. The reporting invoice type is adjusted accordingly.
Duplicate protection
Before anything is written, the connector looks for a document already recorded for that supplier and that supplier invoice reference. A duplicate is reported as a duplicate, not as a failure.
The document image travels with it
The original PDF is uploaded and linked to the invoice in a single operation, so a document never sits in your system without its source. Where that is not possible, the file is linked immediately afterwards.
Items managed in batches
Where an item is managed in batches, the batch read off the document is recorded on the line: the value that, if missing, would stop the invoice being added.
Master data for whoever checks
Suppliers, items, the chart of accounts, tax groups, warehouses, units of measure, cost centres and document series are read live from your system, so whoever checks an invoice in Dijit.app picks from what really exists in SAP.
Several companies
One integration, every company database
Businesses running Business One hardly ever run a single entity. The integration keeps its own isolated session for each company database, so invoices from different entities are processed side by side without interfering: each with its own user, its own document series, its own default warehouse and its own default expense account.
Sessions are reused while they remain valid and renewed before they expire, so the same user does not authenticate again for every document. When the service stops, every open session is closed properly and the licences they occupied are freed, rather than being left to expire on your server.
Every invoice either lands properly in your accounts or fails with a reason somebody can act on. There is no third ending.
How it connects
Over the Service Layer, with nothing installed
The integration uses the Service Layer that comes with SAP Business One: the same published interface your add-ons and reporting tools already use. There is nothing to import into your system, no user object to create for the integration itself and no change to the standard behaviour of documents. The documents it creates are ordinary purchase invoices: they are seen, posted and reported exactly like the ones your team keys by hand.
Access and security
- A named SAP user, per company. The integration connects with the credentials you supply and works within that user's permissions, nothing wider. It takes a licence like any other connected user.
- Sessions properly managed. They are held only while they are useful, renewed before they expire and closed tidily when the service stops, so the licences come free again.
- TLS to your server. If the Service Layer sits behind a private network with an internal certificate authority, that is catered for. If it is reachable from outside, a trusted certificate is expected.
- Ready for the cloud. On hosted deployments, the integration can reach your system through a gateway you control, with an additional shared secret on every request, rather than exposing the Service Layer directly.
- The read scope is narrow. Beyond the documents it creates, the integration only reads the master data it needs to complete them.
Tax treatment
The part that has to come out right
Getting an invoice into SAP is simple. What is hard is getting the tax right in a Spanish company's purchase ledger, invoice after invoice, and that is where this integration puts its effort. The classification logic is the same one our S/4HANA integration uses, so a group running both systems gets consistent tax treatment.
| Situation | How it is handled |
|---|---|
| Domestic purchase in Spain | Classified by rate, including the zero and reduced rates. |
| Intra-Community acquisition of goods | Reverse charge, by rate: the VAT is self-accounted rather than paid to the supplier. |
| Intra-Community services received | Reverse charge, whatever rate the document shows. |
| Imports from outside the EU | Recognised as an import, not as a domestic purchase. |
| Deferred import VAT | Recognised as a case of its own, not mixed in with an ordinary import. |
| Capital goods | Handled separately from running costs, domestically and intra-Community alike. |
| Income tax withholding (IRPF) | Recorded on the document with its rate and its amount. |
Immediate VAT reporting, filled in by default
Companies inside Spain's immediate VAT reporting regime need every purchase invoice to carry its reporting fields: the invoice type, the accounting period and year, the transaction date and a description of what was bought. The integration fills them in on every document it creates, building the description out of the invoice's own lines.
The technical name of those fields varies with the SAP partner who implemented your system, so they are configuration rather than an assumption: the names are taken from whoever maintains your system and used as given.
Nothing is guessed. The mapping between a tax situation and one of your tax groups is agreed with your finance team before going live. A situation with no agreed mapping stops the invoice and says exactly what is missing. The alternative, a normal-looking posting with the wrong tax group, is one of those errors nobody sees until an inspection turns up.
Going live
What we need from your system
Going live is a short, well-defined list. Almost all of it is your team and your SAP partner confirming what already exists, rather than building anything new.
- 01The Service Layer reachable from where Dijit.app runs, over TLS, with whatever certificate arrangement you prefer.
- 02A user and a licence for each company database that will receive invoices, allowed to add purchase invoices and credit notes.
- 03The company databases identified, each with the document series, default warehouse and default expense account it should use.
- 04A session with your finance lead to agree which tax group belongs to each tax situation.
- 05The names of the VAT reporting fields your SAP partner defined, if your company is inside that regime.
- 06Confirmation of how you keep tax numbers on your business partner master, so that finding the supplier works first time.
- 07Which items are managed in batches, so their lines arrive with the batch SAP insists on.
- 08A test database for the first documents. Nothing reaches your real company until the invoices have been verified in test.
Scope
What it does today and where it is going
Saying where the edges are is more useful than a longer list of features.
Outside the current version
- Matching against the purchase order. Invoices are created on their own, without being checked against an open order or its goods receipts. Three-way matching is the next big capability.
- Several batches on one line. Today a line carries one batch. Documents that split a single line across several batches need the road-map improvement.
- Serial numbers. Items managed in batches are covered; those managed by serial number are not yet.
- Credit notes linked to their original invoice. Credit notes are created, but they stand alone rather than referring to the invoice they correct.
- Outbound documents. The integration is about purchasing. It reads your system for master data and only writes purchase invoices and credit notes.
On the road map
- Matching against purchase order and goods receipt.
- Several batches per line, fitted to what suppliers actually put on a delivery note.
- Linking each credit note to the invoice it corrects.
- Finding items by the supplier's own reference, not only by your item code.