The flows
Invoice and credit note
Four kinds of invoice leave Dynamics from four different postings. They are one family on the wire and four flows underneath, 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, one family
| 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, in the project formats |
| A credit note, of any of the three | A credit note in the matching format |
On the wire these are close relatives: the same envelope, mostly the same fields. Inside Dynamics they come from different journals, and that is why they are separate agreements and separate flows. A free text invoice has no order to hang from, and a project invoice is built by the project module, not the sales one.
The Danish standard formats
For UBL there are four standard Danish formats: a sales invoice and its credit note, and a project invoice and its credit note. The module ships none of them; they are Electronic Reporting configurations you import and bind on the agreement. They are not something to author or adjust. They are the published national standard, and the reason a Danish public authority can read your invoice at all.
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, with its own agreement, and it appears on its own tracker 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
A credit note is its own document type, not an invoice with a negative sign. Receivers treat them differently, they reference the invoice they correct, and in the Danish formats they are a separate standard. Agree them separately with the partner, because a partner who accepts your invoices does not necessarily accept your credit notes.
Receiving invoices
As a buyer, an incoming invoice can be matched to the purchase order and the receipt, and posted when the three agree. 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.