Hvordan sjekker jeg en leverandør før jeg betaler en faktura?

Hvordan foregår fakturasvindel mot norske selskaper?

De vanlige formene er identitetstriks, ikke tekniske angrep. En faktura utgir seg for å komme fra et selskap som ikke finnes, eller låner identiteten til et som gjør det. Et navn velges så det ligner til forveksling på en leverandør du allerede betaler, med et annet organisasjonsnummer under. Eller enheten er reell, men skulle aldri vært betalt: et selskap som gikk konkurs eller ble slettet fra registeret for måneder siden, holder et brevhode i live og fortsetter å fakturere.

Det disse formene har felles, er at registeret kan se dem. Et nummer som ikke løser til noe, en status som sier konkurs, et forvekslingsnavn festet til feil organisasjonsnummer: hvert av dem er et rent faktum i Enhetsregisteret, lesbart før noen betaling legges i kø. Sjekken koster ett oppslag og fanger den svindelklassen som er avhengig av at du ikke ser etter.

Vær ærlig om grensen. Det andre klassiske grepet er et endret kontonummer på en ellers ekte faktura, og ingen registeroppslag kan se betalingslinjen i et dokument. Selskapskontroller og kontroller på kontosiden er separate lag, og denne veiledningen dekker bare det første. Ingenting her er en garanti mot svindel; det er laget som fjerner de billige angrepene, og som gjør de gjenværende dyrere å gjennomføre.

Hva bør jeg sjekke før jeg betaler?

Fire kontroller, i den rekkefølgen de fjerner risiko. Eksistens først, fordi alt annet er meningsløst hvis nummeret ikke løser til noe. Status deretter, fordi registrert ikke er det samme som aktivt: et selskap under konkursbehandling eller avvikling står fortsatt i registeret, og en slettedato vinner over alt annet i statusutledningen.

Så de to kontekstkontrollene. Beregner fakturaen MVA, bør leverandøren stå i Merverdiavgiftsregisteret, siden registrering er pliktig fra 50 000 kroner i avgiftspliktig omsetning over rullerende tolv måneder; fakturert MVA fra et uregistrert selskap er et rødt flagg verdt en pause. Og signaturretten forteller om personen bak avtalen i det hele tatt plausibelt representerer selskapet, med det ærlige forbeholdet at de åpne dataene ikke alltid ser ordningen: svaret er da unknown, aldri et påstått fravær.

Hvordan kjører jeg hele sjekken i ett kall?

Ett GET-kall til verify-endepunktet returnerer én verification_status med pass, warn, fail eller unknown, pluss signalene per kontroll bak den: om selskapet er aktivt, alt-klart-flaggene for konkurs og oppløsning, MVA-registrering, og om signaturrett er synlig. Svaret bærer kildemetadata og et ferskhetstidsstempel, så du kan vise hvor hvert faktum kom fra og hvor gammelt det er.

Utfallssemantikken er bevisst konservativ. Fail betyr at selskapet ikke er aktivt registrert. Unknown betyr at en konsultert kilde ikke så nok til å avgjøre, oftest fordi de åpne rolledataene ikke viser signeringsordningen, og det er en stopp, ikke et mykt pass: rut fakturaen til et menneske og sjekk manuelt. Godkjenn aldri en unknown automatisk, for hele poenget med utfallet er at taushet fra registeret ikke er bevis for noe.

Hvordan legger jeg sjekken inn i fakturaflyten?

Sjekk minst to ganger: én gang når leverandøren registreres hos deg, og én gang rett før første betaling. De to øyeblikkene kan ligge uker fra hverandre, og registerdata beveger seg imellom; et selskap kan åpne konkursbehandling etter at kontrakten er signert og før første faktura forfaller. Onboardingsjekken validerer forholdet, sjekken før betaling validerer pengeflyttingen, og ingen av dem erstatter den andre. Begge er ett kall, så kostnaden ved å kjøre dem er i praksis null målt mot en feilutbetaling.

For en løpende leverandørbase er det sløsing å slå opp hvert selskap før hver kjøring. Den bedre formen er å følge registerendringer som en strøm og bare verifisere leverandørene som faktisk endret seg, og holde fakturaene deres tilbake til et ferskt utfall foreligger. Lagre utfallet og tidsstempelet ved siden av leverandørposten, slik at hver frigivelse kan spores til en navngitt kontroll på et navngitt tidspunkt.

Gjør det første kallet

Sandkassekallet returnerer samme utfallsform uten nøkkel, på simulerte data, så du kan bygge hold-eller-betal-grenen først. TypeScript-eksempelet kjører den live sjekken med API-nøkkel og handler på utfallsfeltet slik en betalingskjøring bør: pass frigir, alt annet holdes tilbake.

# Nøkkelløs sandkasse: samme verify-utfall, på simulerte data.
curl -s https://www.apier.no/api/v1/sandbox/public/company/999999999/verify

// Live verify: ett GET-kall, ett utfall, før betalingskjøringen.
const res = await fetch(
  "https://www.apier.no/api/v1/company/999999999/verify",
  {
    headers: {
      Authorization: `Bearer ${process.env.APIER_API_KEY}`,
    },
  },
);

if (!res.ok) {
  // Alle ikke-2xx-svar bruker den samme strukturerte konvolutten.
  const { error_code, explanation } = await res.json();
  throw new Error(`${error_code}: ${explanation.summary}`);
}

const { data } = await res.json();
// Handle på utfallsfeltet, aldri på ett signal alene:
// pass -> frigi betalingen som planlagt,
// warn eller fail -> hold fakturaen tilbake for manuell vurdering,
// unknown -> stopp og sjekk manuelt. Godkjenn aldri unknown automatisk.
switch (data.verification_status) {
  case "pass":
    console.log("klart for betaling:", data.summary);
    break;
  default:
    console.log("hold tilbake:", data.verification_status, data.signals);
}

Ofte stilte spørsmål

Hva er den raskeste enkeltsjekken før jeg betaler en faktura?

Slå opp organisasjonsnummeret og les statusen. Ett oppslag svarer på om selskapet finnes i det hele tatt, og om det er aktivt eller konkurs, under avvikling eller slettet. Det siler ut de groveste identitetstriksene: oppdiktede avsendere og fakturaer sendt i navnet til selskaper som ikke lenger driver. Valider sifrene først, for et nummer som stryker på MOD-11-kontrollsifferet er en tastefeil, ikke et selskap. Har du plass til nøyaktig ett API-kall, gjør det til verify-kallet, som folder denne og de andre kontrollene inn i ett utfall.

Garanterer aktiv status at fakturaen er ekte?

Nei. Registerkontroller fanger svindel på selskapsnivå: identiteter som ikke finnes, selskaper som er konkurs eller slettet, og MVA fakturert av et selskap utenfor Merverdiavgiftsregisteret. De kan ikke se betalingslinjen på selve fakturaen. En ekte utseende faktura fra en reell, aktiv leverandør kan fortsatt bære et endret kontonummer, og ingen registeroppslag oppdager det. Behandle utfallet som ett nødvendig lag, og kombiner det med kontroller på kontosiden, for eksempel å bekrefte et nytt eller endret kontonummer gjennom en kanal du allerede stoler på.

Bør jeg sjekke en leverandør jeg allerede kjenner, på nytt?

Ja, fordi registerfaktaene bak onboardingsjekken ikke står stille. En leverandør som var aktiv i forrige kvartal, kan siden ha åpnet konkursbehandling eller gått under avvikling, og å betale inn i et bo skaper akkurat det rotet sjekken skal forhindre. Kallet er billig og deterministisk, så det praktiske mønsteret er å kjøre det på nytt før første betaling til enhver ny leverandør og periodisk for resten, eller å følge registerendringer som en strøm og bare verifisere selskapene som faktisk endret seg.

Hva betyr utfallet warn?

En advarsel mellom pass og fail: selskapet er aktivt registrert, men en konsultert kilde fastslår at ingen signaturrett er definert. I en betalingsflyt bør den behandles som fail: hold fakturaen tilbake og vurder manuelt. I praksis ser du den sjelden i dag, fordi de åpne rolledataene ikke kan bevise at en ordning mangler, bare la være å vise den, og det ærlige gapet kommer som unknown i stedet. Utfallslisten beholder warn slik at en fremtidig kilde som kan bevise fravær, gir en advarsel og ikke et pass.

Er sjekken gratis, og må leverandøren samtykke?

Faktaene bak er åpne registerdata fra Brønnøysund, publisert for gjenbruk, så det kreves ikke samtykke fra leverandøren for å lese dem. Du kan kalle Enhetsregisteret selv uten nøkkel. Apiers selskapsendepunkter, verify inkludert, krever API-nøkkel også på gratisnivået, fordi selskapsdata bærer rategrenser per nøkkel og et revisjonsspor; sandkassespeilet av det samme utfallet er nøkkelløst og svarer med simulerte data, så du kan bygge flyten ende til ende før du registrerer noe som helst.