Hvad er en payment i HubSpot?

Sådan virker payment-objektet i HubSpot

En payment-række opstår ikke af sig selv. Den bliver skabt, når penge bevæger sig gennem et af HubSpots betalingsværktøjer: et betalingslink, et accepteret tilbud, en faktura eller et abonnement. Siden maj 2026 kan den også oprettes, uden at pengene har rørt HubSpot overhovedet, fordi funktionen til at registrere eksternt behandlede betalinger gik i generel tilgængelighed efter en offentlig beta i april. Netop dét gør objektet relevant herhjemme, hvor de fleste fakturaer stadig betales med en bankoverførsel.

Properties. Rækken bærer bruttobeløb, nettobeløb efter gebyrer og refusioner, betalt beløb, platformgebyr og behandlingsgebyr som selvstændige felter, plus betalingsmetode, kortets eller kontoens sidste fire cifre, udstedende bank, eventuel digital wallet og adskilte fakturerings- og leveringsadresser. Nettobeløbet kan være negativt efter en refusion, og det overrasker de fleste, første gang de bygger en rapport på feltet. Hele listen med de labels, der faktisk vises i UI’et, står i HubSpots oversigt over payments- og subscriptions-properties.

Status er det felt, alt andet hænger op på. En betaling kan stå som Processing, Succeeded, Failed, Partially refunded, Refunded eller Processing refund, og dertil kommer fire dispute-tilstande: handling påkrævet, afventer afgørelse, vundet og tabt. Betalinger, I selv opretter eller registrerer på en faktura, får status Succeeded med det samme, for der er ingen processor, der skal bekræfte noget.

Objektet hænger sammen både opad og nedad i datamodellen. En payment kan associeres med kontakter, virksomheder, deals, fakturaer, ordrer, tilbud, line items og rabatter, hver med sit eget association type ID. Det er den kobling, der gør, at betalingen dukker op i højresidepanelet på kontaktkortet, og at I kan bygge rapporter på tværs af objekter uden at oprette en eneste custom property.

Payments-oversigten. Selve listen ligger under Commerce og lader jer filtrere på status og betalingsdato, eksportere til CSV, XLS eller XLSX, se transaktionsgebyrerne pr. betaling via Actions-menuen og udstede refusioner direkte fra rækken. Manuelt registrerede betalinger kan ikke refunderes den vej, hvilket er logisk nok, når der ikke er nogen processor at rulle noget tilbage hos. HubSpots vejledning til at administrere payments gennemgår hvert trin.

Hvilken processor der står bag, gemmes på rækken selv. HubSpot payments og Stripe payment processing skriver begge ind i det samme objekt, så en virksomhed, der skifter fra det ene til det andet, beholder historikken i én rapport. Feltet med processortype hører derfor med i enhver økonomirapport, hvis I har kørt med mere end én opsætning.

API’et. Payments kan læses og skrives gennem CRM-API’et med scopes til commercepayments, men afgrænsningen er skarp: I kan oprette og opdatere registreringer af eksterne betalinger, og I kan ikke oprette en betaling, der skal behandles. Rækker, som HubSpot payments eller Stripe selv har skabt, kan hverken ændres eller slettes gennem API’et. De redigerbare felter, blandt andet initial amount, latest status, currency code, payment method type og payout date, er listet i HubSpots API-dokumentation for payments.

Gemte betalingsmetoder hører også til her. En kontakt kan have flere kort liggende, efter at HubSpot gjorde det generelt tilgængeligt i maj 2026, og et abonnement kan trække på det rigtige af dem. Kun kort og ACH kan gemmes. BACS og SEPA Direct Debit kan ikke, og det rammer netop de europæiske betalingsformer, en dansk virksomhed ellers ville pege på.

Den fejl, vi oftest ser i opsætningen, er at behandle payments som virksomhedens omsætningstal. Objektet registrerer, hvornår pengene kom ind, ikke hvornår omsætningen skal indregnes, og et forudbetalt årsabonnement lander som ét beløb i én måned. Skal der periodiseres, sker det i økonomisystemet eller på abonnementsobjektets felter for månedlig og årlig tilbagevendende omsætning, ikke på betalingerne.

Den anden klassiker er moms og valuta. Momssatsen sidder på line item og ikke på betalingen, så en tilbagevendende betaling, der er sat op uden sats, tager ikke momsen med ned i tallene. Betaler kunden desuden i en anden valuta end jeres, lægger Stripe 2 procent oveni for omregningen, og det beløb trækkes fra nettobeløbet uden at røre bruttobeløbet.

Vi sætter payment-objektet op, så det passer til en dansk opsætning: Stripe som processor, momssatser på line items, registrering af bankoverførsler fra e-conomic eller Business Central, og de workflows, der rent faktisk gør noget ved en fejlet betaling. Skal I have betalingsstatus ind i CRM’et, eller vil I have et nøgternt regnestykke på, hvad gebyrerne kommer til at koste jer, så tag fat i os.

Hvad danske B2B-teams bruger payments til

De fleste danske virksomheder møder objektet bagfra. De begynder ikke med at tage imod kortbetalinger på nettet, men med at ville have betalingsstatus ind i CRM’et, så salg og service kan se det samme som bogholderiet. Herunder er de anvendelser, vi oftest bygger, og de er stillet op i den rækkefølge, de typisk kommer i.

Bankoverførsler registreret på fakturaen
Bogholderiet markerer fakturaen som betalt eller importerer betalingerne samlet fra et kontoudtog, og hver betaling bliver til en payment-række med status Succeeded og en association til fakturaen. En rådgivningsvirksomhed med 60 fakturaer om måneden kan på den måde give sælgerne adgang til betalingsstatus uden at give dem adgang til e-conomic. Opsætningen tager en formiddag, fordi det eneste, der skal besluttes, er hvem der har rettigheden til at registrere en betaling.

Forudbetaling ved accept af tilbud
Et betalingslink lægges ind i tilbuddet, så kunden betaler første rate i samme klik som accepten i stedet for at vente på en faktura. Et dansk softwarehus, der tager 25 procent ved kontraktunderskrift, flytter dermed starten på onboarding fra to uger til samme dag. Sidegevinsten er, at betalingen selv sætter deal-fasen videre, så ingen sælger behøver huske det.

Varsling på fejlede abonnementsbetalinger
Et workflow lytter på status Failed og opretter en opgave til den kundeansvarlige plus en mail til kunden med et link til at opdatere kortet. Sammenholdt med abonnementsrækken giver det en churn-varsling, der kommer før opsigelsen i stedet for efter. Det er den anvendelse, der oftest betaler for hele opsætningen, fordi et udløbet kort ellers bliver opdaget, når kunden har nået at overveje noget andet.

Rykkerflow på forfaldne fakturaer
Fakturaer uden en tilhørende betaling efter forfald udløser en række påmindelser med stigende alvor. En dansk grossist med 30 dages netto kan lade de to første rykkere køre automatisk og først involvere en medarbejder ved den tredje, hvor tonen alligevel skal tilpasses kunden. Fordi rykkeren sendes fra CRM’et, ser sælgeren den i tidslinjen, inden hun ringer om et mersalg.

Rapportering på betalt omsætning
En rapport på payments ved siden af rapporten på vundne deals viser forskellen mellem, hvad der er solgt, og hvad der er betalt. Netop det tal mangler en dansk ejerleder typisk, når likviditeten strammer, og det kræver ingen integration til banken. Husk bare, at gebyrerne står i separate felter, så en rapport på bruttobeløb og en på nettobeløb giver to forskellige svar.

Betalingshistorik i kundeservice
Payments vises på kontakt- og virksomhedskortet, så en medarbejder i Help Desk kan se, om kunden har betalt, før hun svarer på en klage over manglende adgang. Det sparer den rundtur til bogholderiet, der ellers tager en halv dag. Med et view, der filtrerer på status Failed og Disputed, kan supporten desuden fange de sager, der er på vej til at blive sure, inden kunden selv skriver.

Fællesnævneren er ikke automatiseringen. Den er, at betalingsdata står samme sted som salgs- og servicedata, så ingen skal gætte. Ingen af dem kræver udvikling. Selve registreringen af betalinger og betalingslinkene virker på det gratis niveau, så længe Stripe er processor, mens alt det, der udløses automatisk, forudsætter workflows og dermed Professional i det relevante Hub.

Alternativer, priser og begrænsninger

Payment-objektet er gratis at have. Det, I betaler for, er at få penge igennem det, og der findes flere veje, en dansk virksomhed realistisk kan vælge imellem.

Stripe payment processing i HubSpot
Standardløsningen herhjemme. I forbinder jeres egen Stripe-konto, betalingerne behandles hos Stripe og skrives ind i HubSpots payment-objekt, og HubSpot lægger 0,75 procent oveni som platformgebyr. Stripes egne satser for en dansk virksomhed er pr. september 2026 1,5 procent plus 1,80 kr. for EØS-kort og 3,15 procent plus 1,80 kr. for øvrige internationale kort ifølge Stripes prisside for danske virksomheder, og der lægges 2 procent oveni, når valutaen skal omregnes.

HubSpot payments
HubSpots egen processor, hvor HubSpot står for både behandling og udbetaling. Den kan I ikke bruge. Den er kun tilgængelig for virksomheder registreret i USA, Storbritannien eller Canada, og satserne er derefter: 2,9 procent på amerikanske kort plus 0,5 procent i platformgebyr, og 0,8 procent på ACH med et loft på 10 dollar, som beskrevet i HubSpots FAQ om betalingsgebyrer og lande. Den står med her, fordi en stor del af det engelsksprogede materiale om HubSpot payments beskriver noget, en dansk virksomhed ikke kan købe.

e-conomic med betalingslink og en HubSpot-integration
Betalingen opstår i økonomisystemet og synkroniseres den anden vej. e-conomic koster pr. september 2026 fra 249 kr. om måneden ekskl. moms for Basis op til 649 kr. for Komplet ifølge e-conomics egen prisoversigt, og dertil kommer prisen på integrationen. Fordelen er, at bogføringen er kilden. Ulempen er, at betalingsdata i HubSpot bliver en kopi med forsinkelse, og at selvbetjening for kunden kræver et ekstra værktøj.

Stripe Billing uden HubSpot
Hele abonnements- og faktureringsmotoren hos Stripe, med HubSpot som rent CRM. Pr. september 2026 koster den 4.400 kr. om måneden på en etårig kontrakt eller 0,7 procent af faktureringsvolumen efter forbrug. Den er stærkere end HubSpot til sammensatte prismodeller med forbrug og trin, og svagere på alt, der handler om at koble betalingen til en sælger, en pipeline eller en supportsag.

Zoho Billing
Et selvstændigt faktureringssystem til den, der ikke vil betale HubSpot-priser. Standard koster 39 dollar om måneden ved årlig betaling og Premium 79 dollar pr. september 2026, med et loft på en million dollar i årlig omsætning og 100.000 fakturaer om året. Til gengæld skal koblingen til CRM’et bygges og vedligeholdes af jer selv.

Den manuelle proces
Bankkontoudtog, en deal-fase der hedder Betalt, og en person, der flytter kortene. Den koster ingenting og holder overraskende længe. Den falder typisk fra hinanden et sted mellem 50 og 100 fakturaer om måneden, eller i det øjeblik nogen skal kunne svare på, hvor mange kunder der er bagud, uden først at åbne et regneark.

Hvor vinder HubSpot så. Svaret er sammenhængen og ikke betalingsmotoren. Ingen af alternativerne kan uden videre lade et workflow reagere på en fejlet betaling ved at tildele en opgave til den sælger, der ejer virksomheden, og samtidig vise historikken i den indbakke, supporten sidder i. Omvendt taber HubSpot klart på afregningen. Der er ingen dansk momsafstemning, ingen kontoplan og intet revisorspor, og satserne bliver en anelse dyrere end at gå direkte til Stripe, netop fordi platformgebyret lægges oveni.

Prisen på selve platformen blev lettere at gennemskue efter omdøbningen. Pr. september 2026 koster Revenue Hub 0 dollar for op til to brugere, 85 dollar pr. sæde om måneden ved årlig betaling for Professional, 95 dollar ved månedlig betaling, og 140 dollar for Enterprise ifølge HubSpots prisside for Revenue Hub. Professional følger 3.000 HubSpot Credits med, Enterprise 5.000.

Det væsentlige for payment-objektet er, at I ikke behøver Professional. Betalinger, fakturaer, betalingslinks og gemte betalingsmetoder findes på alle niveauer, også det gratis, når Stripe er processor. Abonnementer kræver Professional, og det samme gør tilbud og CPQ med godkendelsesflows og elektronisk underskrift, hvor Professional giver 25 underskrifter pr. bruger om måneden og Enterprise 50. Vil I derimod have et workflow til at reagere på en fejlet betaling, er det ikke payment-objektet, der koster: workflows kræver Professional i Marketing Hub, Sales Hub eller Service Hub. Et sæde er i øvrigt knyttet til en person og ikke til en betaling, så bogholderiet behøver ikke et sæde for at betalingerne bliver registreret.

Grænserne er værd at kende, før I lover noget. En enkelt korttransaktion kan højst være 250.000 dollar eller tilsvarende, og en ACH-betaling 100.000. Udbetalinger tager typisk to til fire hverdage efter betalingsdagen. Ved en chargeback har I 20 dage til at svare. Sandbox- og udviklerkonti kan ikke forbindes til en processor, og det betyder, at betalingsflows ikke kan testes ordentligt, før de er live. Det er den enkeltbegrænsning, der oftest koster en weekend.

Koblingen til Stripe har sin egen faldgrube. Fakturaer og abonnementer, I opretter i HubSpot, bliver ikke oprettet i Stripe, sådan som HubSpots vejledning til at forbinde en Stripe-konto beskriver det, og hver Stripe-konto kan kun kobles til én HubSpot-konto. Kører I allerede abonnementer i Stripe, har I derfor to steder med hver sin sandhed, indtil I migrerer. HubSpot åbnede for selvbetjent migrering af Stripe-abonnementer den 29. maj 2026, og den sætter automatisk abonnementet i Stripe på pause, når flytningen er gennemført.

Dansk og europæisk kontekst afgør, hvor meget af det her I overhovedet kan bruge. Kortdata gemmes aldrig hos HubSpot. De tokeniseres hos Stripe, og på payment-rækken står kun de sidste fire cifre og udstederen, hvilket holder objektet uproblematisk under GDPR, så længe I afholder jer fra at kopiere kortoplysninger ind i noter. Moms sættes på line item, og HubSpot gjorde standardsatser generelt tilgængelige den 7. april 2026, så en dansk konto kan lægge 25 procent på automatisk. Bogføringsloven flytter sig ikke af den grund. En payment-række er ledelsesinformation og ikke bogføringsmateriale, og regnskabet skal stadig føres i e-conomic, Business Central eller hvad I nu bruger.

Der findes også tilfælde, hvor svaret er nej. Sælger I udelukkende på 30 dages netto til 20 faste kunder, der betaler ved bankoverførsel, får I meget lidt ud af at registrere betalinger i HubSpot ud over et pænere overblik. Det samme gælder, hvis prismodellen er så forbrugsbaseret, at faktureringen alligevel skal beregnes et andet sted. Er I derimod på vej mod abonnementer, selvbetjening eller bare et rykkerflow, der ikke afhænger af én persons hukommelse, hører payments til de første ting, vi sætter op. Resten af billedet har vi samlet i vores gennemgang af HubSpot-platformen.