Document Denmark inbound invoice responses

apps/denmark.mdx

@@ -56,6 +56,7 @@ import FAQ from '/snippets/faqs/dk/composers/app-nemhandel.mdx';
 		* **Delivery confirmation:** The send step waits until the network confirms delivery — submission alone doesn't complete the job, and duplicates are never resubmitted.
 		* **Hosted supplier onboarding:** The authorisation agreement is signed through a hosted wizard, with API endpoints for integrators building their own onboarding UI.
 		* **Push reception:** Inbound documents are delivered by webhook the moment they arrive and handed to your import workflow.
+		* **Invoice responses:** A received OIOUBL ApplicationResponse becomes its own status entry, with the outcome — accepted or rejected — available for workflow branching.
 
 		Check out the guides below to get started:
 		- [Supplier registration](/guides/dk-nemhandel-supplier) · [Issuing invoices](/guides/dk-nemhandel) · [Receiving invoices](/guides/dk-nemhandel-receiving)
@@ -77,7 +78,7 @@ import FAQ from '/snippets/faqs/dk/composers/app-nemhandel.mdx';
 		| Invoice reception | <Badge color="green">Available</Badge> | Webhook push into your import workflow |
 		| Party deregistration | <Badge color="green">Available</Badge> | Releases the participant and its inbound routing |
 		| Reminders | <Badge color="yellow">In development</Badge> | OIOUBL Reminder documents are planned for a follow-up release |
-		| Invoice responses | <Badge color="yellow">In development</Badge> | The OIOUBL ApplicationResponse leg is planned for a follow-up release |
+		| Invoice responses | <Badge color="green">Available</Badge> | Received ApplicationResponses become status entries with the outcome on the job result; linking a response to the invoice it answers is planned for a follow-up release |
 
 	</Tab>
 
@@ -115,7 +116,7 @@ import FAQ from '/snippets/faqs/dk/composers/app-nemhandel.mdx';
 		Reception
 
 		<Card title="Load from NemHandel" icon="https://assets.invopop.com/flags/dk.svg" horizontal>
-		 Fetch one received document, parse the OIOUBL, and create a GOBL silo entry with the original XML and its embedded attachments.
+		 Fetch one received document, parse the OIOUBL, and create a GOBL silo entry with the original XML and its embedded attachments. An invoice becomes a `bill/invoice` entry; an application response becomes a `bill/status` entry with its outcome on the job result.
 		</Card>
 	</Tab>
 

guides/dk-nemhandel-receiving.mdx

@@ -14,7 +14,7 @@ import { dkNemhandelImportWorkflow } from '/snippets/workflows/dk/nemhandel-impo
 
 Documents sent to a registered party's NemHandel participant are pushed to Invopop the moment they arrive: eCourier notifies the [Denmark app](/apps/denmark) by webhook, and the app starts your import workflow for each document. There is no polling schedule to wait for — received invoices show up as soon as the network delivers them.
 
-Each received document becomes exactly one silo entry carrying the GOBL invoice, the original OIOUBL XML, and any binary attachments embedded in it, so received invoices show up like any other workflow-processed document.
+Each received document becomes exactly one silo entry carrying the GOBL document, the original OIOUBL XML, and any binary attachments embedded in it, so received invoices show up like any other workflow-processed document.
 
 Registering the parties themselves is covered in the companion guide: [NemHandel supplier registration](/guides/dk-nemhandel-supplier).
 
@@ -65,7 +65,8 @@ A few behaviours worth knowing:
 
 - **Delivery is push, not polling.** The network's webhook triggers the import within moments of a document arriving.
 - **Documents are acknowledged only after import succeeds.** A failure partway through leaves the document ready on the network to retry, so nothing is lost to a transient error; the network redelivers on its own schedule.
-- **Unsupported document types are surfaced, not looped.** The current release imports invoices and credit notes. An OIOUBL ApplicationResponse or Reminder is acknowledged once and the import job fails with a message naming the document type and the participant it was addressed to, so it's visible instead of being retried forever.
+- **Invoice responses become status entries.** An OIOUBL ApplicationResponse — the message a customer sends back accepting or rejecting an invoice — is imported as its own `bill/status` silo entry, with the original XML attached. The import job's result carries the outcome (`accepted`, `rejected`, …), so your workflow can branch on it.
+- **Unsupported document types are surfaced, not looped.** An OIOUBL Reminder, or a response profile the app cannot process, is acknowledged once and the import job fails with a message naming what arrived and the participant it was addressed to, so it's visible instead of being retried forever.
 - **Embedded attachments are preserved.** Binary attachments carried inside the OIOUBL document are extracted and stored on the silo entry alongside the XML.
 
 ## FAQ

guides/dk-nemhandel.mdx

@@ -72,6 +72,10 @@ The bytes stored on the entry are exactly the bytes that reached the network, so
 
 Running the send workflow again on an invoice that was already delivered skips with a `Duplicated Invoice` result instead of resubmitting, so a retried or repeated run never delivers the document twice.
 
+### Hearing back from the customer
+
+Delivery confirms the document reached the customer's access point; whether they accept it is a separate answer. A customer who responds with an OIOUBL ApplicationResponse does so through the receiving flow: the response is imported by your import workflow as its own status entry, with the outcome — accepted or rejected — available for branching. See [Receiving invoices](/guides/dk-nemhandel-receiving).
+
 ### Generating without sending
 
 The convert step also works on its own: a workflow that ends after **Generate OIOUBL** produces the validated XML attachment without submitting anything, which is useful for previewing the exact document a customer will receive.

snippets/components/workflow.jsx

@@ -5,6 +5,7 @@ export const WorkflowDiagram = ({ workflow }) => {
     received: "blue",
     registered: "green",
     completed: "green",
+    rejected: "red",
     error: "red",
   };
 

snippets/faqs/dk/leaves/nemhandel/receiving.mdx

@@ -4,8 +4,11 @@
 <Accordion title="Which workflow processes inbound documents?">
   The one you select in the Denmark app's configuration (**Configuration** → **Apps** → **Denmark** → **Configure**). Every inbound document is handed to that workflow, so create it before registering any party — its first step must be the app's import action, and everything after it is yours to shape: setting a state, filing into a folder, or any other processing.
 </Accordion>
+<Accordion title="How do I know if an invoice I sent was accepted or rejected?">
+  When the customer answers with an OIOUBL ApplicationResponse, it arrives through the same import workflow as received invoices and becomes its own `bill/status` silo entry, with the original XML attached. The response document records the customer's answer, and the import job's result carries the outcome — `accepted` or `rejected` — so your workflow can branch on it.
+</Accordion>
 <Accordion title="What happens to document types Invopop cannot process?">
-  The current release imports invoices and credit notes. If something else arrives — an OIOUBL ApplicationResponse or a Reminder — the app acknowledges it on the network once and fails the import job with a message naming the document type that arrived and the participant it was addressed to, so it's visible rather than silently retried forever. Support for these document types is planned for a follow-up release.
+  If something arrives that the app cannot process — an OIOUBL Reminder, or a response profile it does not implement — the app acknowledges it on the network once and fails the import job with a message naming what arrived and the participant it was addressed to, so it's visible rather than silently retried forever. Support for Reminders is planned for a follow-up release.
 </Accordion>
 <Accordion title="Can a document be delivered twice?">
   The network redelivers its webhook until it is acknowledged, but the import step only acknowledges a document after it has been fully processed — and a document that was already imported isn't imported again. A failure partway through leaves the document ready to retry rather than lost.