Documentation/ ERP integrations/ SAP S/4HANA
Supplier invoices straight into SAP S/4HANA
Dijit.app reads a supplier invoice, a PDF or a scan, and posts it as a supplier invoice in SAP S/4HANA, with the document image attached, the right tax code on every line and a duplicate check before anything is written. All over SAP's standard OData interfaces: no bespoke ABAP and nothing to install in your system.
Standard interfaces only
Your Basis team switches on services SAP publishes. Nothing is developed inside your system.
Spanish tax rules built in
Domestic purchases, reverse charge, imports, capital goods, deferred import VAT and income tax withholding.
It does not guess
An invoice it cannot classify with certainty fails with a specific reason. It never invents a tax value.
Your configuration governs
Tax codes, withholding types, company codes and accounts come from your set-up, not from values of ours.
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 tax number and against the VAT registration on the business partner master, so it works with whichever your system keeps.
Tax classification line by 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. The result is translated into your tax code, agreed with your finance team before you go live.
Duplicate protection, twice over
Before posting, it looks for an invoice already recorded for that supplier, that reference and that company code. SAP's own check is the second net: either of them stops the document and reports it as a duplicate, not as an error.
The document image travels with it
The original PDF is uploaded and linked to the posted invoice, so anybody opening the document in SAP sees the original. If the attachment fails, the posted invoice is not unwound: you are told the image is missing.
Withholding is treated as money, not as a label
Income tax withholding is posted with its base on the net amount, as Spanish rules require. If a withholding rate has no agreed counterpart, the invoice fails: a withholding is never dropped in silence.
Master data for whoever keys the invoices
Supplier lookup, the chart of accounts and the item search are served live from your system, so whoever checks an invoice in Dijit.app picks from what really exists in SAP.
How it connects
SAP's published interfaces, with nothing installed
The integration talks to your gateway over the OData services SAP publishes and documents for exactly this. Your Basis team switches them on and gives a technical user the authorisations to post. There is no transport to import, no ABAP to review and no modification of any kind in your system.
A short, specific list of services covers all of it: posting supplier invoices and credit notes, reading the supplier and material masters, reading the chart of accounts and attaching the document image. We hand the exact list to your Basis team during the roll-out.
Authentication and security
- One technical user, with exactly the scope it needs. The integration authenticates as a single service user, allowed to read the master data it needs and to post supplier invoices. Nothing more.
- Basic or OAuth 2.0. Both are supported. On-premise systems usually use a technical user with basic authentication. Where there is a token issuer in front of the gateway, the client credentials flow is used, with tokens renewed before they expire and reissued at once if the gateway rejects one.
- The gateway session is handled the way SAP expects. CSRF tokens and session cookies are handled by its own mechanics, including transparent recovery when a token expires mid-session.
- Your certificate policy governs. The connection to your gateway runs over TLS. If the gateway 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.
- Client and language on every call. The SAP client and language are sent explicitly, so a production configuration never touches a test client by mistake.
Every posting either lands properly in your accounts or fails with a reason somebody can act on. There is no third ending.
Requirements by type
What each document type needs
SAP does not ask the same of a purchase invoice as of an expense. This is the table that settles this integration's most repeated question: why some documents send with no items assigned and others do not.
Document › items tab › ERP item assignment
| Document type | Item | Account | Batch |
|---|---|---|---|
| Purchase invoice | Yes | Yes | Yes |
| Transport invoice | Yes | Yes | Not applicable |
| Expense invoice | Not asked for | Yes | Not applicable |
The application sums it up in its own help: purchase invoices need item, account and batch; transport invoices, item and account; expenses, only the account.
Purchase invoices
These are the most demanding: every line needs an item from the catalogue, a nominal account and a batch.
- The item is picked from the list. It takes no free text.
- The account can be left empty if the item already has its own in SAP.
- The batch is typed in its column, which on this document type is always shown, even if the user had hidden it in the column picker.
The batch column being forced visible on purchase invoices is no accident: hidden, the value would be missing and the sending would fail with no visible cause.
Transport invoices
These need an item and an account. They carry no batch, because carriage does not move goods with traceability of its own.
The expiry date column does not appear on this type either, for the same reason.
Expense invoices
These need only the nominal account. And on this type, the assignment dialogue does not even show the item search or the reference code: only the account is in view.
Looking for the item field on an expense invoice is looking for something that, by design, is not there.
Why it works this way
The logic is accounting, not technical:
| Type | What it records | What SAP needs |
|---|---|---|
| Purchase | Goods coming into the warehouse. | To know which item comes in and from which batch, for stock and traceability. |
| Transport | A service attached to goods. | To know what it is for and where it is charged. |
| Expense | Consumption that never touches the warehouse. | Only where it is charged. |
An electricity bill has no warehouse item. Asking for one would mean inventing a value.
A check before sending
Before sending a batch to SAP, a quick pass by type:
- On purchase invoices, look at the ERP column: any line showing a dash is missing its item. And check the Batch column is filled in.
- On transport, the same with the item and the account.
- On expenses, just check there is an account.
The ERP badge on the item list is the quickest way: with a value, the line is assigned; with a dash, it is not.
Things that come up
| What you see | Why | What to do |
|---|---|---|
| An expense sent with no items assigned and a purchase did not | The requirements differ by type. | Not a fault. It is each type's rule. |
| The batch is missing and the column cannot be seen | The document is not a purchase invoice. | On other types the batch is neither handled nor asked for. |
| SAP rejects a purchase for want of a batch | Some line has it empty. | Fill it in in the Batch column and send again. |
| The item search is not there | It is an expense invoice. | Fill in the nominal account, which is all that is asked for. |
| The account was left empty and it went to a different one | SAP worked it out from the item or used the default. | State it expressly on that line. |
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. That is the real work, and it is where this integration puts its effort.
Cases covered
| Situation | How it is handled |
|---|---|
| Domestic purchase in Spain | Classified by rate, including the zero and reduced rates. The VAT is charged by the supplier and forms part of what is owed to them. |
| Intra-Community acquisition of goods | Reverse charge. The supplier is paid the net. The VAT is self-accounted by your company; it does not cross the border. |
| Intra-Community services received | Reverse charge, whatever rate the document shows. |
| Imports from outside the EU | Handled as self-assessment. The supplier is paid the net and import VAT goes its own way. |
| 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, because the tax code is different. |
| Income tax withholding (IRPF) | Posted with its base on the net amount, using the withholding type and code from your configuration. |
Two details that decide whether the document goes in
The gross amount is what is genuinely owed to the supplier. On a reverse charge or import line, adding the VAT to the amount payable produces a document SAP rejects and a debt that is wrong. VAT is added to the total payable only where the supplier actually charges it.
VAT is rounded once per tax code, over the grouped net. That is how SAP's own invoice entry does it. Rounding line by line and then adding up drifts by a penny on an ordinary invoice of several lines, and a penny is enough for the document to be rejected.
Nothing is guessed. The mapping between a tax situation and one of your tax codes is agreed with your finance team before going live and stored as configuration. A situation with no agreed mapping stops the invoice and says exactly what is missing. The alternative, a normal-looking posting with the wrong code, 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 Basis and finance teams confirming what already exists, rather than building anything new.
- 01Network access to your gateway — reachable from where Dijit.app runs, over TLS, with whatever certificate arrangement you prefer.
- 02The standard services switched on — registered in your service maintenance transaction, from the list we give you.
- 03A technical user authorised to read the master data involved and to post supplier invoices in the relevant company code.
- 04Company code and chart of accounts for each legal entity that will receive invoices, plus a default expense account and cost centre for lines that arrive without them.
- 05A session with your finance lead to agree the tax codes for each tax situation, and the withholding types and codes if income tax withholding applies.
- 06Confirmation of how you keep tax numbers on your supplier master, so that finding the supplier works first time.
- 07Document management configured if you want the invoice image attached to the posted document.
- 08A test client for the first postings. Nothing reaches production until the documents have been verified in your quality system.
Scope
What it does today and where it is going
Saying where the edges are is more useful than a longer list of features. The current version posts invoices against general ledger accounts, which is what suits expense purchasing, where the invoice is the first document in the chain.
Outside the current version
- Matching against the purchase order. Checking an invoice against an open order and its goods receipts, three-way matching, is the next big capability. Until it arrives, lines are posted against accounts rather than against order items.
- Items filtered by supplier. The relationship between supplier and material lives in the purchasing info records. Reading those is part of the same work as order matching.
- Batches and serial numbers. In S/4HANA these belong to the goods receipt, not the invoice. A batch read off a document is carried as a reference on the line; it is not posted as stock data.
- Plants and storage locations. They only mean anything once posting against an order exists.
- Outbound documents. The integration is about purchase invoices. It reads your system for master data and only writes supplier invoices and credit notes.
On the road map
- Matching against purchase order and goods receipt, with lines posted against order items.
- Items offered by supplier, from the purchasing info records.
- Mapping to customer fields of your own on the invoice document.
- Parking documents for a person to release inside SAP, as an alternative to posting directly, for finance teams who want a human step in their own system.
- Linking each credit note to the invoice it corrects.