Invoice and credit note
Four kinds of invoice leave Dynamics from four different postings. Underneath they are two journals and two agreements, and the difference matters when one of them does not arrive.
Invoicing is where EDI is most often required rather than chosen. Public sector customers in Denmark cannot accept a paper invoice, and a large retailer will pay an electronic invoice weeks earlier than a posted one. It is also the flow where a rejection costs the most, which is why it is the one to put validation on.
Four sources, two agreements
On the wire these are close relatives: the same envelope, mostly the same fields. Inside Dynamics they come from two journals and two business processes. A sales order invoice, a free text invoice and the credit notes of both post a customer invoice journal and travel under the Sales order invoice agreement. A project invoice and its credit note post a project invoice journal and travel under the Project invoicing agreement, because a project invoice is built by the project module, not the sales one.
| What you post | What goes out |
|---|---|
| A sales order invoice | An invoice against the order it belongs to |
| A free text invoice | An invoice with no order behind it |
| A project invoice | An invoice for work done, raised in the project module |
| A credit note, of any of the three | A credit note in the matching format |
Project invoicing is its own business process for a reason that shows up the day a customer takes both. If the project invoice shared the sales invoice process, a partner holding both would be ambiguous on every posting, and nothing could say which format an invoice should leave in.
The project pair exists on UBL alone. Neither EDIFACT nor X12 carries a project invoice as a document of its own, so a partner who wants one is a partner you trade with in UBL. Both UBL dialects have a project pair, and the section below applies to project invoicing exactly as it does to sales.
Two UBL dialects
On UBL a Danish invoice is OIOUBL 2.1 and a European one is Peppol BIS. They share the UBL syntax and even the root element, and they are judged by different rules, so the module carries them as separate document types rather than as one type with a switch on it. A partner is on one or the other, and the module refuses two of them on the same posting rather than letting the choice be undefined.
The temptation, when a receiver rejects an invoice, is to edit the format until it passes. That produces something that passes for one receiver and fails for the next. If a standard invoice is rejected, the answer is nearly always in the data rather than the format: a missing reference, an identifier the receiver does not recognise, or lines that do not sum to the total.
The free text invoice
The free text invoice used to be the quiet gap in most EDI setups: an invoice with no order behind it, posted by finance rather than by sales, and sent by email because nobody had wired it up. It is a proper flow here. It needs no agreement of its own: it travels under the sales invoice agreement you already have with that partner, and it appears on its own tracker on the free text invoice rather than nowhere.
Totals, and why a verdict has to wait
An invoice is not finished at the moment it is created. The header exists before the amounts are on it, and the amounts land as the posting completes. Anything that checks an invoice therefore has to run after that, not during.
This is worth knowing because it explains a behaviour that otherwise looks like a bug: a validation rule about totals cannot be evaluated at the point the invoice row appears. The module waits, and the verdict you see is taken from the finished invoice.
Credit notes
Whether a credit note is its own document type depends on the format. On UBL it is: the invoice and the credit note are two document types on one business process, and you need an agreement for each. A posting that finds only the other half of the pair is refused rather than sent under the wrong root element, so agree the pair together or not at all.
On EDIFACT and X12 one document type carries both, so the invoice agreement covers the credit note too, and the wire tells them apart by the message function on the document. Either way a credit note is not an invoice with a negative sign: receivers treat them differently, and they reference the invoice they correct.
Receiving invoices
As a buyer, an incoming invoice is matched against the purchase order and what was received against it. Where the three agree it is saved into Pending vendor invoices, carrying the supplier’s own invoice number, for the people who already approve invoices. EDI posts nothing to the ledger. That is on the purchase side, and it is the flow with the largest saving in it for most companies, because it is the one that currently involves a person reading a PDF.