EHF/Peppol-integrasjon

Teknisk spec for hvordan DigiReq leverer Peppol BIS Order 3.0 til kundens innkjøps-/ERP-system og hvordan automatisk faktura-matching fungerer.

1. Verdiforslag

I dag matches faktura mot rekvisisjon manuelt: en saksbehandler i økonomi finner papirskjemaet, sjekker beløp, og godkjenner faktura for utbetaling. Tar 3-5 minutter per faktura. Med automatisk matching:

• Faktura med matchende rekvisisjonsnummer + beløp innenfor toleranse → auto-godkjent for utbetaling
• Avvik (feil leverandør, beløp utenfor toleranse, ugyldig nummer) → flagges for manuell gjennomgang med all kontekst tilgjengelig
• Forventet besparelse: 80-90 % av match-arbeid for rekvisisjons-baserte fakturaer

2. Arkitektur

DigiReq er push-side — vi sender data ved godkjenning, ikke ved forespørsel. Kundens ERP (typisk Visma) er stateholder — den kjenner sin egen faktura-flow og kombinerer purchase order + faktura for matching.

Rekvisisjon godkjent  ─► [POST/Fil/Webhook] ─► Innkjøps-/ordremodul
                                                  │
                                Faktura ankommer  │
                                                  ▼
                                    Slå opp ordre på rekvisisjonsnummer
                                                  │
                                              Match? Ja → auto-godkjent
                                                      Nei → flag for review

2.1 Eksempel-kontekst: kommune som migrerer til skybasert økonomisystem

Mange kommuner oppgraderer i disse år fra eldre, hostede økonomisystemer (on-prem) til skybaserte plattformer som Visma Enterprise Plus. EHF-mottak via Visma access point fungerer både før og etter en slik migrasjon, så vår SFTP/EHF-leveranse er det minst risikable alternativet gjennom overgangen.

Visma Enterprise Plus har moderne REST API + OAuth; legacy Visma Enterprise har SOAP. Direkte API-integrasjon (alternativ C nedenfor) vurderes etter Visma Plus er live hos kunden.

3. Hva DigiReq sender ved godkjenning

Felt-spesifikasjon (uavhengig av leveringsformat):

3.1 Beløps-toleranse for match

• Estimat-bekreftelse aktiv (anbefalt): ±2 % eller ±50 NOK (det største). Realistisk auto-match-rate: 60-80 % første måned, opp mot 90 % etter leverandør-onboarding.
• Estimat alene (fallback hvis ansatten ikke bekrefter): ±10 % eller ±200 NOK. Forventet auto-match-rate ~50 %.

Toleransen er konfigurerbar per kunde. Tools/byggvarer har ofte små avvik; faste tjenester (abonnement) bør være ±0 %.

3.2 Bekreftelses-flyten

1. Rekvisisjon godkjennes → første EHF-ordre sendes med estimated_amount
2. Ansatten handler i butikken
3. Ansatten åpner rekvisisjonen i appen, taster faktisk beløp fra kvitteringen
4. DigiReq oppdaterer actual_amount_nok + audit-logger
5. Ny EHF-ordre med samme cbc:ID resendes med presis beløp
6. Leverandørens faktura matches mot oppdatert ordre

4. Leveringsalternativer

4.1 SFTP med EHF-XML (anbefalt for pilot)

DigiReq genererer én fil per godkjent rekvisisjon (eller batch hver 15 min) og laster opp til en SFTP-mappe avtalt med kunden. Kundens innkjøps-/ERP-system plukker den opp i sin import-flyt.

Eksempel — EHF Order utdrag (Peppol BIS 3.0):

<?xml version="1.0" encoding="UTF-8"?>
<Order xmlns="urn:oasis:names:specification:ubl:schema:xsd:Order-2">
  <cbc:CustomizationID>urn:fdc:peppol.eu:poacc:trns:order:3</cbc:CustomizationID>
  <cbc:ID>NV-443-2026-0001</cbc:ID>
  <cbc:IssueDate>2026-05-28</cbc:IssueDate>
  <cac:BuyerCustomerParty>
    <cac:Party>
      <cac:PartyName><cbc:Name>Eksempel kommune</cbc:Name></cac:PartyName>
      <cac:PartyIdentification>
        <cbc:ID schemeID="0192">959469059</cbc:ID>
      </cac:PartyIdentification>
    </cac:Party>
  </cac:BuyerCustomerParty>
  <cac:SellerSupplierParty>
    <cac:Party>
      <cac:PartyName><cbc:Name>Eksempel byggvarehus</cbc:Name></cac:PartyName>
    </cac:Party>
  </cac:SellerSupplierParty>
  <cac:OrderLine>
    <cac:LineItem>
      <cbc:Quantity unitCode="EA">1</cbc:Quantity>
      <cbc:LineExtensionAmount currencyID="NOK">2400.00</cbc:LineExtensionAmount>
      <cac:Item>
        <cbc:Description>Arbeidshansker, str. 10</cbc:Description>
      </cac:Item>
    </cac:LineItem>
  </cac:OrderLine>
</Order>

Filnavn-konvensjon: digireq-{requisition_number}-{ISO8601}.xml

SFTP-detaljer som må avklares med kunde:

• Hostname og port
• Bruker + offentlig SSH ed25519-nøkkel (vi genererer)
• Mappe-sti for opplasting
• Forventet hentings-frekvens fra kunde-side (vi tilpasser batch-vinduet)

Feilhåndtering: Filer som ikke kan parses logges hos oss og re-prøves neste batch. Ingen retransmit-storm — én ID per rekvisisjon, ny opplasting overskriver med høyere version-nummer.

4.2 HTTPS-webhook

For kunder med integrasjons-plattform (Logic Apps, Boomi, MuleSoft, Frends).

DigiReq POSTer JSON ved godkjenning til kunde-definert URL:

POST https://kundens-middleware.example.no/webhooks/digireq
Authorization: Bearer <kunde-issued-secret>
X-DigiReq-Signature: sha256=<HMAC-SHA256>
Content-Type: application/json

{
  "event": "requisition.approved",
  "version": "1.0",
  "occurred_at": "2026-05-28T10:23:14Z",
  "data": {
    "requisition_number": "NV-443-2026-0001",
    "buyer_reference": "ANS443",
    "approved_by_name": "Kari Nordmann",
    "estimated_amount": 2400.00,
    "currency": "NOK",
    "description": "Arbeidshansker, str. 10",
    "status": "approved"
    // ... resterende felt fra §3
  }
}

• Sikring: HMAC-SHA256 over timestamp + body (replay-beskyttelse), bearer-token, TLS 1.2+ påkrevd
• Retry: 3 forsøk med eksponentiell backoff (10s, 60s, 5min). Etter feilet retry: audit-logg + admin-varsel
• Idempotens: Unik requisition_number som idempotency-key

4.3 Peppol AP (via Tickstar Galaxy)

For kunder som mottar over Peppol-nettverket og ikke vil sette opp SFTP/webhook. DigiReq sender via Tickstar Galaxy som vår access point — AS4-transport mellom AP-er er signert og kryptert i tråd med Peppol-spesifikasjonen. Avsender-identitet er kundens org-nr (0192:<org>); mottakerens AP slås opp via SMP.

Forutsetning: kunden mottar Peppol Order over nettverket (ikke alle gjør det i dag — de fleste kommuner mottar f.eks. kun Invoice, ikke Order). Vi verifiserer dette i onboarding.

5. Hva som må avklares før utvikling starter

Til kunde-IT:

1. Hvilken Visma-modul (eller annen ERP) mottar fakturaer i dag, og hvilken modul håndterer purchase orders?
2. Eksisterer SFTP-mottakskanal for EHF fra leverandører? Kan vi bruke samme kanal eller egen mappe?
3. Integrasjons-middleware (Logic Apps, Frends, Boomi)? Hvis ja, foretrekker dere webhook?
4. Toleranse for auto-match? (Forslag: ±2 % med estimat-bekreftelse)
5. Hva skal skje ved avvik? Auto-flag, e-post-varsel, eller annet?
6. Hvor lenge oppbevares purchase order i Visma før utløp? (Vi setter utløps-dato for å unngå at gamle rekvisisjoner matcher feil faktura.)

Til DigiReq-side:

1. Mappe avdeling → kostnadssted før første faktura, eller berikere senere?
2. Leverandørliste-sync fra Visma først, eller starte uten?
3. OK med SFTP som default, og oppgradere til webhook senere?

6. Estimat og tidslinje

For pilot med SFTP/EHF-XML:

1. Uke 1: Avklaring m/ kunde-IT: SFTP-detaljer, format-valg, kostnadssted-mapping
2. Uke 2: DigiReq genererer EHF-XML, opploadt til SFTP. Test-modus mot test-Visma
3. Uke 3: End-til-end-test med faktiske test-rekvisisjoner og test-fakturaer
4. Uke 4: Toleranse-justering, edge-case-håndtering (ikke-match, dobbelt-faktura, kreditnota)
5. Uke 5: Go-live i pilot-modus. Markus + kunde-IT følger første 50 fakturaer manuelt
6. Uke 6: Oppfølging + finjustering

Total 6 uker fra avtalt pilot-start til full automatisk matching for rekvisisjons-baserte kjøp.

7. Sikkerhet

• Tilgangskontroll: Hver kunde har egen SFTP-mappe / webhook-endpoint — ingen krysskontaminasjon
• Kryptering: All transport over TLS 1.2+ (HTTPS) eller SFTP (SSH)
• Autentisering: SSH-nøkkel-basert for SFTP, bearer-token + HMAC for webhook
• SFTP host key pinning (TOFU): pinner serverens host key på første vellykkede tilkobling, verifiserer mot pinnet fingerprint før hver leveranse
• Audit: Alle utgående integrasjons-kall logges i DigiReq audit-log med request-ID, timestamp og status. Tilgjengelig i admin-dashboard
• Personvern: Kun rekvisisjons-metadata sendes — ingen helse, ingen særlig sensitive kategorier. Underbygd av DPA §3 og §4

8. Versjonering og bakoverkompatibilitet

• Bakoverkompatible endringer (nye optional felt) → samme versjon
• Ikke-bakoverkompatible (felt-rename, struktur-endring) → ny versjon; gammel støttes minst 6 mnd

9. Hva som ikke er i scope for første versjon

• Toveis-sync: Visma sender ikke data tilbake. Kan legges til hvis kunden vil.
• Kreditnota-håndtering: Første versjon støtter rekvisisjon → faktura. Kreditnota matchet mot opprinnelig rekvisisjon kommer senere.
• Delvis-leveranse: Faktura med lavere beløp enn rekvisisjon (del-leveranse) håndteres som avvik for manuell vurdering.

Vedlegg A — Eksempel-flow

Scenario: En ansatt i et kommunalt foretak lager rekvisisjon på arbeidshansker hos et byggvarehus for 2 400 kr. Lederen godkjenner. Tre dager senere kommer fakturaen.

T+0      Ansatt oppretter rekvisisjon i DigiReq
T+0:01   Leder får push, godkjenner med slide-to-approve
T+0:02   DigiReq genererer EHF Order-XML med ID NV-443-2026-0001
         Lastes opp til /sftp/kunde/digireq/inbox/
T+0:15   Visma plukker opp filen i neste batch-runde
         Lagrer som purchase order m/ status "godkjent, venter faktura"
T+3 dgr  Byggvarehuset sender EHF-faktura til kommunen
         Faktura inneholder NV-443-2026-0001 i referanse-feltet
         Beløp: 2 380 NOK (avvik 20 kr fra anslag)
T+3:00   Visma matcher: rekvisisjon finnes, leverandør stemmer,
         beløp innenfor ±2 %, status "godkjent"
         → Auto-godkjent for utbetaling
T+5 dgr  Byggvarehuset får utbetaling. Saksbehandler i økonomi har ikke
         rørt fakturaen.

Avvik-scenario: Hvis fakturaen kom på 5 000 NOK (langt over toleranse), flagges saken til økonomi-saksbehandler med all kontekst (rekvisisjon, faktura, godkjenner, innkjøper, beskrivelse). Saksbehandler avgjør: ny godkjenning fra godkjenner, eller avvis faktura tilbake til leverandør.

Dokument-versjon 1.0 · Sist oppdatert 6. mai 2026 · info@digireq.no