Fakturaer (fordringer)

Renteloven § 3 stk. 3: rente tidligst 30 dage efter fakturaens afsendelse. Forta Pay kender kun sine egne afsendelser; en faktura sendt fra e-conomic, et tidligere opkrævningssystem eller i hånden får derfor ingen automatisk rente, før kreditor her har dokumenteret dagen og beviset. ÉN gang (409 external_dispatch_already_registered); ikke på en kladde (409 invoice_not_issued); datoen hverken i fremtiden eller før fakturadatoen (422).

K15: findes external_ref allerede hos kreditoren, svares 200 med den eksisterende faktura (idempotent import). 🔴 På en live-konto sætter Forta Pay reminder_level_initial: en værdi > 0 giver 403 reminder_level_platform_only (håndhævet i databasen). Fordringer der allerede er rykket i FarPay, tages ind gennem POST /imports. Sandkassen er uændret.

Hvad der må rettes afhænger af fakturaens tilstand (stykke PATCH-1, K30). ✅ = tilladt, ellers 409 med koden.

| Tilstand | due_date | distribution | collection_instruction | dunning_plan_id | metadata | |---|---|---|---|---|---| | draft | ✅ (≥ issue_date) | ✅ | ✅ | ✅ | ✅ | | open | ✅ (≥ i dag og ≥ issue_date) | ✅ (kun fremtidige udsendelser) | ✅ | ✅ | ✅ | | overdue, dunning | due_date_locked — brug dunning/pause | ✅ | ✅ | ✅ (planen regnes om) | ✅ | | ready_for_collection, in_collection | invoice_in_collection | ← | ← | ← | ✅ | | paid, credited, cancelled, written_off | invoice_closed | ← | ← | ← | ✅ | | importhold (importeret, skiftet ikke aktiveret) | invoice_import_hold | ← | ← | ← | ✅ | | opkrævning med ukendt udfald | charge_outcome_unknown | ← | ← | ← | ✅ |

Ændres due_date eller collection_instruction mens en opkrævning er submitted/accepted: 409 charge_in_flight (med charge_id). Er den scheduled, annulleres den og planlægges igen efter de nye værdier i samme transaktion.

metadata er JSON Merge Patch (RFC 7396): en nøgle med null fjerner nøglen. De øvrige felter erstattes helt; udeladt felt = uændret. Ukendt felt → 422. Hele kaldet er atomisk. En rettelse til samme værdier (no-op) giver 200 og INGEN hændelse. Ellers udsendes præcis én invoice.updated med previous = de ændrede felter. warnings indeholder distribution_future_only når distributionen rettes på en faktura der allerede er sendt.

TILFØJET af pay-rest-udbydere 28-09-2026 (b14). Kræver at OIOUBL er slået til for kreditoren (creditor_oioubl_settings.enabled, standard fra). Generatoren gætter intet: EAN med gyldigt tjekciffer, personreference, struktureret adresse, linjer der summerer til total og en betalingsmåde (42 bank / 93 FIK) skal findes — ellers 422 med feltet og OIOUBL-reglens id. Dokumentets UUID er deterministisk pr. faktura. Forta Pay sender ikke filen videre (ingen VANS/adgangspunkt er forbundet).

TILFØJET af pay-rykkerbevis 15-10-2026 (D8). Ét bevis pr. faktura til kreditor, revisor og CRM: hver skrivelse (hvad, hvornår, frist, dokumentets sha256), hver leverance (kanal, modtager, status, leverandørens kvitteringer og post-/mailjournalens række) og hjemlen pr. gebyr og rente, ordret som den blev skrevet på hændelsen da beløbet blev bogført (rule_source: event) — ellers koden regel (rule). Afsendelse er H9's bevis, fremkomst R-18's (kun e-Boks' leveringskvittering eller brevets omdeling; en e-mail beviser aldrig fremkomst). reference er de første 64 bit af evidence_sha256 = sha256 af beviset (sorterede nøgler, uden mellemrum, uden reference/evidence_sha256). Samme journal giver samme reference, JSON og PDF-bytes; as_of er seneste post i journalerne, ikke uret. Sker der noget nyt på fakturaen, er det et nyt bevis med en ny reference. ?reference= efterprøver en reference man har: 409 evidence_changed med den gældende, hvis den ikke er den.

Fire øjne: har kreditoren slået fire øjne til, svarer kaldet 202 med en ApprovalRequest (status: pending) i stedet for at annullere. En ANDEN person på kreditoren godkender den i kreditorfladen; først da annulleres fakturaen. Kaldet prøves først: et kald der ville fejle nu, får samme fejl som uden fire øjne. Slået fra (standarden) er svaret uændret.

Fire øjne: har kreditoren slået fire øjne til, svarer kaldet 202 med en ApprovalRequest (status: pending) i stedet for at kreditere. En ANDEN person på kreditoren godkender den i kreditorfladen; først da udstedes kreditnotaen. Kaldet prøves først: et kald der ville fejle nu, får samme fejl som uden fire øjne. Slået fra (standarden) er svaret uændret. Bogføring: krediteringen UDEN dokument skrives ALDRIG i kreditorens regnskabssystem (e-conomic, Dinero m.fl.), heller ikke når Forta Pay bogfører kreditorens indbetalinger. Kaldet SPEJLER en kreditnota der er udstedt og bogført i regnskabssystemet (fx af jeres eget system) — Forta Pay læser ikke kreditnotaer ind derfra. Skrev Forta Pay den også, stod krediteringen to gange. Skal Forta Pay udstede OG bogføre kreditnotaen, brug /invoices/{id}/credit-notes. Spejling med external_ref (spor pay-refusion-f0, bag FORTA_PAY_REFUSIONSORDRER): kildens kreditnota-id gemmes; samme external_ref + samme beløb igen = 200 uden ny kreditering (også under fire øjne); samme ref med et andet beløb eller på en anden faktura = 409 external_ref_conflict. En betalt faktura kan spejles: saldoen bliver negativ (kundens tilgodehavende), status urørt, loft = hovedstolen (422 credit_exceeds_invoice). Det er trin 1 før POST /creditors/{creditorId}/refund-orders. Slukket: uændret. Skygge: tilladt for en kreditor i skygge (collection_mode: shadow) — kaldet spejler kun og sender, bogfører og opkræver intet. Har fakturaen en planlagt opkrævning, aflyses den; i skygge planlægges der ikke en ny på restbeløbet (det tidligere system opkræver). TILFØJET af pay-credit-skygge 18-10-2026: før svarede en DELVIS kreditering af en faktura med planlagt opkrævning 409 creditor_in_shadow.

TILFØJET af pay-kreditnota 15-10-2026 (C2). Præcis én af lines (fakturalinjens indeks + antal; aldrig mere end der er tilbage på linjen) og amount (inkl. moms; momssatsen er fakturaens når den er entydig, ellers vat_rate). Alle kreditnotaer på fakturaen tilsammen ≤ fakturaens total (credit_note_exceeds_invoice). settlement er PÅKRÆVET, uden standard: · credit_balance («tilgodehavende»): lagt på fakturaens restbeløb (som /credit, med dens værn — en indleveret opkrævning giver 409 charge_in_flight). Det der overstiger restbeløbet, står som unapplied_amount: et tilgodehavende hos kreditor. Det modregnes IKKE automatisk i en senere faktura. · refund («pengene tilbage»): den eksisterende refund-vej (/payments/{id}/refund, invoice_effect: credit) på payment_id (udeladt = fakturaens eneste refunderbare betaling, ellers 422 payment_required). Kort/MobilePay betalt gennem Forta Pay sendes tilbage af PSP'en (refund_mode: psp); alt andet er en registrering af at kreditor selv betaler tilbage (external, B1). reversal_id er refundens id. Nummeret tages i kreditorens nummerserie i samme transaktion (fortløbende, intet hul). send: true (standard) sender kreditnotaen på de kanaler FAKTURAEN nåede debitor på; er fakturaen ikke sendt af Forta Pay, sendes intet (deliveries: []). Udsendelsen kan ikke vælte kreditnotaen. Kreditor i skygge → 409 creditor_in_shadow. Hændelse: credit_note.created (saldoen følger stadig invoice.credited). Fire øjne: som /credit — har kreditoren slået fire øjne til, svarer kaldet 202 med en ApprovalRequest (action: api-credit-note, status: pending); kreditnotaen udstedes (og sendes) først når en ANDEN person har godkendt den i kreditorfladen. Kaldet prøves først (uden at sende): et kald der ville fejle nu, får samme fejl.

TILFØJET af pay-kreditnota 15-10-2026. Samme regler som /invoices/{id}/oioubl (OIOUBL slået til for kreditoren, EAN, personreference, struktureret adresse; ingen gæt). BillingReference peger på fakturaen. Valideret mod den officielle pakke (schematron 1.17.2) — se rapporter/pay-kreditnota-maalinger/oioubl.md.

Ejerskab afgør IKKE om betalingen tages imod (H2, bevidst). Også på en faktura som det tidligere system stadig ejer efter et skifte (shadow: true, fx klasse D hos FarPay), registreres betalingen, og fakturaen går til paid. Så holdes Forta Pays billede af fakturaen ajour. Forta Pay opkræver, rykker og sender stadig ikke på den, og claim, hold og shadow flyttes ikke af betalingen. Kun en aktiv pilots kohorteværn (K3) kan afvise.

Fire øjne (pay-sikkerhed2 T6-7): har kreditoren slået fire øjne til, og er beløbet mindst kreditorens grænse ELLER hele fakturaens restbeløb, svarer kaldet 202 med en ApprovalRequest (action: api-mark-paid, status: pending) i stedet for at registrere. En ANDEN person på kreditoren godkender den i kreditorfladen; først da registreres betalingen (result_id = fakturaen). Kaldet prøves først: et kald der ville fejle nu, får samme fejl som uden fire øjne. Under grænsen og for en del af saldoen, og med fire øjne slået fra (standarden), er svaret uændret.

external_ref er unik pr. faktura (TILFØJET, pay-markpaid-dedup). Er en registrering med samme external_ref allerede på fakturaen (source: external, ikke tilbagetrukket), er kaldet en gensendelse: samme beløb → 200 med fakturaen som den står, intet nyt registreres, ingen hændelse — også med en NY Idempotency-Key, også når den første registrering lukkede fakturaen, og også under fire øjne (ingen ny anmodning). Andet beløb → 409 external_ref_conflict med payment_id og registered_amount. Uden external_ref deduplikeres intet: to kald er to betalinger. En tilbagetrukket registrering (withdraw-registration) tæller ikke, så samme reference kan registreres igen med det rigtige beløb.