Viktigaste slutsatserna

  • Det finns ingen inbyggd koppling mellan en Fortnox-faktura och en HubSpot-affär – du bygger själv ihopslagningen på kund, belopp och ett datumfönster.
  • Marknadsplatskopplingar (till exempel Cloudifys Fortnox-app, eller Resultifys) fungerar bra när affären skapar fakturan – sämre när fakturor redan finns fristående i Fortnox.
  • En egenbyggd API-matchning kräver en tydlig mappning mellan HubSpot-företag och Fortnox-kundnummer, plus en definierad datum- och beloppstolerans – båda manuella och kräver underhåll.
  • Håll koll på del- och kreditfakturor, flervaluta och affärer som motsvarar flera fakturor (eller tvärtom) – en enkel 1:1-matchning missar dessa helt tyst.
  • Vad som än ligger bakom den slutliga avstämda summan bör vara en uttrycklig, upprepningsbar fråga – inte ett manuellt genomögnat kalkylblad.

Varför posterna inte matchar automatiskt

Fortnox-fakturor är bokföringsposter: fält som kundnummer, fakturanummer och saldo, hämtade via Fortnox API:s resurs Invoices. Du kan söka på fält som kundnamn eller filtrera på status – till exempel filter=unpaid för obetalda fakturor – tillsammans med datumparametrar som fromdate och todate.

HubSpot-affärer bär i stället kommersiella fält: affärsnamn, affärsstadium, belopp och stängningsdatum, kopplade till företag och kontakter via ett associations-objekt. Belopp är ett fält på affären, men krävs inte för att skapa en affär – många affärer saknar helt ett angivet belopp.

HubSpots egna standardfält för affärer omfattar belopp, valuta, stängningsdatum och beräknade fält som totalt kontraktsvärde – men inget fält för ett externt fakturanummer eller en Fortnox-kundreferens.

De två systemen delar helt enkelt ingen gemensam nyckel ur lådan. Det som binder ihop en faktura med en affär måste byggas, inte antas finnas.

Två sätt att bygga matchningen i praktiken

Väg A – en marknadsplatskoppling. Cloudifys app "Fortnox – Accounting App for HubSpot", listad i HubSpots egen marketplace, skapar fakturor och ordrar i Fortnox direkt utifrån HubSpot-affärer, synkar kunder och produkter i båda riktningar och visar faktura- och orderstatus inne i HubSpot. Ett liknande alternativ, Resultifys Fortnox-till-HubSpot-app, listas i Fortnox egen integrationskatalog. De fungerar bra när affären är källan till fakturan – du skapar fakturan utifrån affären. De fungerar sämre när fakturor redan finns fristående i Fortnox (abonnemangsfakturering, en annan säljkanal, manuella poster) och ska matchas i efterhand.

Väg B – ett schemalagt matchningsflöde. Hämta fakturor från Fortnox API, filtrerat till exempel på lastmodified eller ett fromdate/todate-intervall, och hämta affärer från HubSpot API med deras kopplade företag. Slå därefter ihop de två på en nyckel du själv definierar – vanligtvis kundens namn eller organisationsnummer plus ett belopp och en datumtolerans, eftersom det inte finns någon delad identifierare att matcha på direkt.

Arbetsflödet i praktiken – och dess begränsningar

En konkret variant av väg B: (1) hämta vunna (closed-won) affärer för perioden, med kopplat företag och belopp; (2) hämta Fortnox-fakturor för samma period, med kundnummer, saldo och fakturanummer; (3) slå ihop på en kundnummer-matchning – mappad en gång, manuellt, från HubSpot-företag till Fortnox-kund – kombinerat med en belopps- och datumtolerans (till exempel faktura utställd inom 30 dagar från stängningsdatum, belopp inom en definierad marginal); (4) resultat: tre listor – matchade, affärer utan faktura, och fakturor utan affär.

Flera saker bryter detta tyst om du inte namnger dem i förväg. Valuta och avrundning: ett affärsbelopp i HubSpots affärsvaluta motsvarar inte nödvändigtvis det fakturerade värdet i SEK när flervalutakonton eller radrabatter är inblandade. Tajming: en faktura kan ställas ut veckor efter att en affär stängs, eller före (a conto-fakturor), vilket spränger ett fast datumfönster. Del- och kreditfakturor: en Fortnox-fakturas saldo och dess avbokade (cancelled) status måste hanteras explicit, annars läses de som falska avvikelser. Många-till-många-relationer: en affär kan motsvara flera fakturor (delbetalningar), eller en faktura kan täcka flera affärer – en enkel 1:1-matchning missar båda. Den svagaste länken är oftast själva mappningstabellen: den manuella listan mellan HubSpot-företag och Fortnox-kundnummer måste byggas en gång och sedan hållas uppdaterad när kunder byter namn eller slås samman.

Checklista innan du litar på avstämningen

Bekräfta vilka fält på HubSpot-affären som faktiskt är ifyllda – belopp och valuta är valfria, inte garanterade.

Bestäm uttryckligen om du matchar mot fakturans saldo, fakturans totalbelopp eller ett nettobelopp efter kreditering i Fortnox – dessa är inte utbytbara.

Sätt en medveten datumtolerans mellan affärens stängning och fakturans utställningsdatum, och skriv ner varför du valde den.

Bygg och versionshantera mappningen mellan HubSpot-företag och Fortnox-kund som en egen artefakt – inte en engångsuppslagning gömd i ett skript.

Redovisa alltid de omatchade listorna – affärer utan faktura och fakturor utan affär – som en del av resultatet, inte som en bortkastad restpost.

Kör om matchningen enligt ett schema om siffran används mer än en gång; ett kalkylblad byggt en gång blir inaktuellt den dag en kundpost ändras.

När en tvåsystemsmatchning inte räcker längre

I det ögonblick du också behöver ställa avstämningen mot en tredje källa – bankbetalningar, ett annat CRM, ett andra faktureringssystem – eller vill att samma matchning ska köras varje vecka och landa någonstans andra kan granska, blir ett skript som limmar ihop två API:er snabbt bräcklig infrastruktur som någon måste komma ihåg att köra och laga. Det är oftast där team börjar leta efter ett gemensamt, styrt hem för mappningen och matchningslogiken i stället för ännu ett privat skript.

Ronjas dataplattform är byggd för att koppla samman befintliga system som Fortnox och HubSpot utan att ersätta dem, och hålla den resulterande mappningen, modelleringen och nyckeltalen som tabeller och frågor som går att inspektera – inte engångskod. Ett ekonomiskt tal som redovisas ska komma från en uttrycklig fråga eller ett program som körs mot verklig data och kontrolleras mot motorns eget resultat, inte påstås. Det ändrar dock inte det underliggande arbetet: du behöver fortfarande behörigheter till källsystemen på båda sidor, en definierad mappning mellan kundposter och en avstämningslogik som namnger sina egna antaganden – inget av detta blir automatiskt bara för att båda systemen är anslutna till samma plattform. Detta är ett representativt mönster, inte en specifik kunds uppmätta resultat.

Källor

Vanliga frågor

Kan HubSpot lagra Fortnox-fakturanumret automatiskt?

Inte som standard. HubSpots vanliga affärsfält innehåller inget fält för en extern fakturareferens. Du behöver lägga till ett eget fält och fylla det via API, eller använda en av marknadsplatsintegrationerna som skriver tillbaka Fortnox-fakturadata till affärsposten i HubSpot.

Kan jag filtrera Fortnox-fakturor till bara de obetalda via API:et?

Ja – resursen Invoices stöder en filter-parameter (till exempel filter=unpaid) tillsammans med datumparametrar som fromdate och todate, så du kan hämta exakt det urval du behöver i stället för hela fakturahistoriken.

Går det att lita på fältet Amount på en HubSpot-affär vid matchning mot ett fakturabelopp?

Se det som en utgångspunkt, inte en garanti. Amount krävs inte för att skapa en affär, och när radartiklar eller flera valutor används kan det skilja sig från fält som totalt kontraktsvärde. Kontrollera vilket fält ditt team faktiskt fyller i innan du använder det för att kontrollera avstämda totalsummor. Ett belopp är inte en tillförlitlig nyckel för att matcha poster.