Att välja en faktureringsleverantör är ett av de viktigaste infrastrukturbesluten som ett växande företag kan fatta. Om du gör det på rätt sätt får du ett system som kan skalas upp efter din prismodell, hanterar global efterlevnad automatiskt och ser till att intäkter flödar på ett tillförlitligt sätt. Om du gör fel riskerar du månader av omarbeten och intäktsläckage.

Stripe Billing ingår som en referenspunkt häri – se det som ett konkret exempel på hur en mogen faktureringsplattform ser ut i produktionen.

Den här mallen ger dig ett strukturerat, heltäckande sätt att hämta offertförslag (RFP) från faktureringsleverantörer med allt från administrativa grundregler till detaljerade krav, kommersiella punkter och utvärderingspoäng. Den är uppbyggd kring de funktioner som är viktigast för abonnemangsföretag 2026: användnings- och multiattributprissättning, återvinning av betalningar med maskininlärning (ML), intäktsanalys i realtid, global efterlevnad av skatteregler och nya krav som agentisk handel och integrerade finansiella produkter.

Den här RFP-mallen är inte avsedd att användas som ett stelt formulär. Det är mer som en guide du kan (och bör) anpassa efter dina specifika behov. Varje avsnitt innehåller anvisningar som hjälper dig att skriva frågor som ger dig användbara svar, och inte bara marknadsföring. Fyll i luckorna med information om ditt projekt, be om detaljer där det är mest viktigt och ta bort allt som inte är tillämpligt. När den används på rätt sätt kan den här RFP-mallen spara tid, avslöja lämpliga leverantörer och ge bättre underlag för ditt slutliga beslut.

Innehåll

• Försättsblad
  
• Avsnitt A: Administrativa instruktioner
  
• Avsnitt B: Översikt och arbetets omfattning
  
• Avsnitt C: Offertanvisningar
  
• Avsnitt D: Utvärderingsprocessen
  
• Avsnitt E: Grundläggande krav
  
• Avsnitt F: Implementering och support
  
• Avsnitt G: Kommersiellt
  
• Avsnitt H: Leverantörsprofil
  
• Avsnitt I: Referenser
  
• Avsnitt J: Bilagor
  

Försättsblad

Målet med försättsbladet är att berätta för leverantörerna exakt vad de tittar på och vem de ska prata med. Inkludera RFP-titel, ditt företags namn, ett kort sekretessmeddelande och kontaktuppgifter för den person som behandlar ärendet. Datum är också viktiga. Lista utgivningsdatumet och förfallodatumet direkt så att ingen kan hävda att de missade dem. Håll försättsbladet kortfattat. Det ska handla om orientering, inte om att visa upp vad ditt designteam kan göra.

Här är vad du ska inkludera i det här avsnittet:

• Titel: RFP för [project/service/product]
  
• Utfärdande organisation: [Your company]
  
• Sekretessmeddelande: (Kort, sekretesskopplat språk)
  
• Kontaktperson: [Name, title, email, phone]
  
• Utfärdandedatum och förfallodatum
  

Du kanske vill designa ditt eget varumärkta RFP-dokument. I så fall kan konturerna i varje avsnitt ge en stark grund. Nedan har vi också lagt till exempeltext som du kan använda.

Viktiga datum

Inlämningsformat
Alla svar måste skickas in elektroniskt via e-post i PDF-format. Mallar för priser och poängsättning (som tillhandahålls separat i Excel) måste bifogas i originalformat.

Konvention om filnamn
[Vendor name]–[Project name]–RFP–Svar–[Date].pdf

Syftet med denna RFP
[Your company] söker en faktureringspartner som kan stödja säkra transaktioner i flera valutor, enkelt integrera med interna system via moderna API:er och leverera hög tillförlitlighet, proaktiv identifiering av bedrägerier och datatransparens i olika regioner.

I det här dokumentet beskrivs kraven, utvärderingskriterierna och processen för att lämna in förslag.

Kort sekretessmeddelande
Denna RFP innehåller konfidentiell och proprietär information som tillhör [your company]. Den tillhandahålls endast i syfte att förbereda ett svar. Distribution utöver de som är direkt involverade i utarbetandet av ett förslag är förbjuden. Genom att acceptera denna RFP samtycker mottagaren till att skydda denna information med minst samma grad av omsorg som de tillämpar för att skydda sin egen konfidentiella information.

Avsnitt A: Administrativa instruktioner

I det här avsnittet fastställs grundreglerna. Innan leverantörer investerar tid i ett svar måste de veta hur processen fungerar, vad som förväntas och hur tidslinjen ser ut. Tvetydigheter här skapar problem senare, så var noggrann.

Här är vad du ska inkludera:

• Sekretess- och tystnadsplikt
  
• Ansvarsbegränsning
  
• RFP-tidslinje med viktiga datum
  
• Konventioner för inlämningsformat och filnamn
  
• Kontaktperson och kommunikationsregler
  
• Formulär för leverantörsbekräftelse
  

Här är ett exempel på hur detta kan se ut.

A.1 Förklaring om konfidentialitet och tystnadsplikt

All information i denna RFP är konfidentiell och endast avsedd att göra det möjligt för leverantören att förbereda ett svar. Leverantören får inte avslöja, reproducera eller distribuera denna RFP eller någon del av den till tredje part utan föregående skriftligt samtycke från [your company]. Om leverantören inkluderar proprietär information i sitt förslag bör den informationen vara tydligt märkt. [Your company] kommer att behandla den därefter.

A.2 Begränsning av ekonomiskt ansvar

Denna RFP är inte ett erbjudande om att ingå ett avtal. [Your company] är inte skyldigt att ingå ett avtal eller ersätta kostnader för att förbereda ett svar. Leverantörerna är ensamma ansvariga för sina egna utgifter under processen.

A.3 Tidslinje för RFP

A.4 Riktlinjer för inlämning

• Alla förslag måste skickas in via e-post till [contact email address].
  
• Leverantörerna måste bekräfta mottagande inom tre arbetsdagar efter utfärdandet.
  
• Frågorna måste lämnas in skriftligen senast det datum som anges i A.3.
  
• All kommunikation måste gå via den utsedda RFP-chefen. Direkt kontakt med andra anställda på [your company] under utvärderingsperioden är inte tillåtet och kan leda till diskvalificering.
  

A.5 Obligatoriska inlämningsdokument

Varje leverantör måste inkludera följande material i sin inlämning.

A.6 Utvärderingsöversikt

[Your company] kommer att utvärdera förslag om faktureringsfunktionalitet, teknisk arkitektur, global efterlevnadstäckning, prestanda för återvinning av betalningar, djup för intäktsrapportering, implementeringsmetod och leverantörsstabilitet. Leverantörer som uppvisar maskininlärningsdriven optimering, realtidsanalys, stark API-prestanda och beredskap för agentisk och AI-initierade faktureringsarbetsflöden kommer att prioriteras.

A.7 Leverantörsbekräftelse

Leverantörer måste fylla i och returnera bekräftelsen nedan inom tre arbetsdagar efter att ha fått denna RFP.

Vi bekräftar mottagandet av RFP med titeln ”[RFP name]” och bekräftar vår avsikt ☐ att skicka in/☐ att inte skicka in ett svar.

Företagsnamn: ________________________

Auktoriserat ombud: ________________________

Titel: ________________________

Datum: ________

Avsnitt B: Översikt och omfattning av arbetet

En vag översikt ger allmänna förslag. Ge leverantörerna det sammanhang de behöver för att svara intelligent, till exempel affärsmodell, priskomplexitet, de marknader du betjänar och de specifika problem du försöker lösa. Du kan även inkludera ytterligare information för att anpassa översikten, inklusive huvudkontor och nyckelmarknader, ungefärliga årliga intäkter eller faktureringsvolym och inblandade interna team (t.ex. ekonomi, teknik, efterlevnad, RevOps, kundframgång).

Här är ett exempel på hur detta kan se ut.

B.1 Företagets bakgrund

[Your company] är ett [global/regional] teknikföretag som är verksamt på [insert markets] och betjänar [insert customer type] med [insert product or service description]. Vår faktureringsverksamhet omfattar [X] marknader och stöder [describe pricing models such as usage-based, subscription, and hybrid plans].

• Vi fakturerar för närvarande [approximate volume] kunder per månad i [X] valutor. Vi söker en faktureringspartner vars plattform kan skalas upp i takt med vår verksamhet, hantera komplex prissättningslogik utan skräddarsydd teknik och uppfyller skatte- och tillsynskraven på varje marknad vi är verksamma på.
  

B.2 Projektets syfte

Denna RFP finns för att identifiera en faktureringsplattform som stöder nästa fas i vår tillväxt. Vår nuvarande konfiguration [describe the gap (e.g., cannot handle usage-based pricing, lacks global tax compliance, doesn’t integrate with our ERP system, cannot support AI-initiated subscription changes)].

Vår ideala partner möjliggör:

• Stöd för flexibla prismodeller – användningsbaserad, fastpris, nivåbaserad, multiattribut- och hybridbaserad på en enda plattform
  
• Automatiserad beräkning av global skatt och efterlevnad av fakturakrav, inklusive omsättningsskatt, moms och landsspecifika format
  
• Branschledande återvinningsgrad för betalningar tack vare maskininlärningsbaserad logik för återförsök och intelligent dunning-hantering
  
• Analys av abonnemang och intäkter i realtid tillgänglig för både tekniska och icke-tekniska team
  
• Enkel integration med våra CRM-, ERP-, datalager- och redovisningssystem via väldokumenterade API:er
  
• Beredskap för agentisk handel – leverantörssystem med stöd för abonnemangsåtgärder som initieras av AI-agenter eller automatiserade arbetsflöden
  

B.3 Arbetets omfattning

Kärnleveranser:

• Heltäckande livscykelhantering för abonnemang inklusive provperioder, uppgraderingar, nedgraderingar, pauser och uppsägningar
  
• Stöd för olika prismodeller som användningsbaserad fakturering med detaljerad aggregering, nivåbaserad prissättning, priser med flera attribut (t.ex. licenser plus användning) och avbetalningsplaner
  
• Automatiserad skatteberäkning och lokaliserad fakturering på alla marknader där [your company] är verksamt
  
• Integration med [CRM, ERP, data warehouse, and accounting systems] via versionsbaserade, dokumenterade API:er
  
• Intäktsredovisning i enlighet med ASC 606 och IFRS 15, inklusive vattenfallsrapportering och hantering av förutbetalda intäkter
  
• ML-driven återhämtning av betalningar med intelligent schemaläggning av nya försök, stöd för nätverkstokens, automatisk kortuppdaterare och konfigurerbara dunning-sekvenser
  
• Dashboards i realtid som täcker MRR, ARR, kundbortfall, konvertering från provperioder och återvinningseffektivitet
  
• Kundsjälvbetjäningsportal för hantering av abonnemang och betalningar
  

Valfria leveranser:

• AI-drivna intäktsprognoser och prediktiv kundbortfallsbedömning
  
• Stöd för konton med flera enheter eller hierarkiska kontostrukturer
  
• Inbäddade faktureringsfunktioner för SaaS-plattformar som säljer vidare till sina egna kunder
  
• Stöd för agentisk handel – API:er och autentiseringsmönster som gör det möjligt för AI-agenter att initiera, ändra och säga upp abonnemang för kundernas räkning
  
• Inbäddade finansiella produkter – stöd för utfärdande, kassa eller utlåningsprodukter integrerade med fakturering
  

B.4 Arbete utanför omfattningen

Definiera vad som är uteslutet så att leverantörer inte prissätter eller tar ansvar för det. Här är några exempel:

• Kärninfrastruktur för betalning (hanteras separat av Stripe)
  
• Identifiering av bedrägerier utöver kontroller på standardnivå för fakturering
  
• Fullständig funktionalitet för ERP eller allmän huvudbok
  

B.5 Önskat resultat

• Andelen återvunna betalningar överstiger [X] % inom sex månader efter lansering
  
• Automatiserad skatteberäkning som täcker [X] marknader vid lansering
  
• Tid till faktura för nya prismodeller reducerad från [current state] till [target]
  
• Fullständig ASC 606-kompatibel intäktsrapportering utan manuell avstämning
  
• Svarslatens för API under 300 ms vid p99 för alla faktureringsåtgärder
  

Avsnitt C: Offertanvisningar

Om du inte anger hur du vill att förslagen ska formateras får du allt från bildspel på fem sidor till PDF-filer på 200 sidor. I det här avsnittet standardiseras vad du får så att du kan jämföra leverantörer sida vid sida.

Här är ett exempel på hur detta kan se ut.

C.1 Format och struktur för inlämning

Varje förslag måste följa denna struktur:

• Exekutiv sammanfattning (max tre sidor)
  
• Uppfyller alla krav i avsnitt E, med numrering
  
• Färdig prissättningsmall i Excel
  
• Leverantörsprofil och ekonomisk sammanfattning
  
• Minst tre kundreferenser
  
• Styrkande dokument som certifieringar av efterlevnad, fallstudier och utdrag ur dokumentation av API:er
  

Inlämningar som avviker avsevärt eller utelämnar obligatoriska inslag kan anses vara icke-överensstämmande.

C.2 Formateringskrav

• Beskrivande svar som PDF, prissättningsmall som Excel-fil.
  
• * Teckensnitt på minst 11 pt, marginaler på en tum, sidnummer krävs.*
  
• Alla monetära siffror i USD om inget annat anges.
  
• Filnamn: [Vendor name]–Fakturering–RFP–[Date].pdf
  

C.3 Vägledning om förslagets innehåll

Exekutiv sammanfattning

• Förklara direkt hur din lösning tillgodoser [your company]s mål i avsnitt B.
  
• Börja med mätbara resultat – återvinningsgrad, förbättrad auktoriseringsgrad och tidslinjer för implementering – inte produktbeskrivningar.
  
• Inkludera din vision för detta partnerskap under tre år.
  

Översikt över lösningen

• Beskriv hur din plattform hanterar komplexa prissättningsscenarier som användningsbaserad mätning, prissättning med flera attribut, ändringar av abonnemang under en cykel och behörighetshantering.
  
• Beskriv API-arkitektur, SDK-tillgänglighet, webhook-tillförlitlighet och sandlådans paritet med produktion.
  
• Förklara hur dina maskininlärningsfunktioner förbättrar återvinningen av betalningar och minskar kundbortfallet.
  

Implementeringsplan

• Ange ett utkast till projektets tidslinje med milstolpar: konfiguration, integration, testning, UAT och lansering. Identifiera leverantörers och kunders ansvar i varje fas.
  

Säkerhet och efterlevnad

• Bekräfta efterlevnad av PCI DSS v4.0 (gäller från mars 2024) och senaste revisionsdatum.
  
• Beskriv alternativ för datahemvist och integritetskontroller för GDPR och CCPA.
  
• Beskriv hur du behandlar incidenter och tidslinjer för avisering till kunder.
  

API och utvecklarfunktioner

• Ange riktmärken för API-latens (p50, p95 eller p99), upptidshistorik och din inställning till versionshantering och bakåtkompatibilitet.
  
• Inkludera en länk till din utvecklardokumentation eller sandlåda.
  

C.4 Förtydliganden och frågor

Frågor måste skickas in skriftligen senast den [question deadline] till [RFP manager’s email]. Svar kommer att skickas ut till alla deltagare samtidigt. Inga informella diskussioner med andra anställda på [your company] är tillåtna under processen.

C.5 Förslagets giltighet

Förslag måste vara giltiga i 90 dagar från tidsfristen för inlämning om de inte förlängs genom skriftlig överenskommelse.

C.6 Rätt att avvisa eller förhandla

[Your company] förbehåller sig rätten att avvisa alla förslag, begära förtydliganden eller inleda parallella förhandlingar med en eller flera leverantörer. Deltagande utgör inte ett åtagande om köp.

Avsnitt D: Utvärderingsprocessen

Transparens i poängsättningen driver leverantörer att svara med bevis snarare än marknadsföringstext. Varje kriterium nedan kopplas till en specifik fråga i avsnitt E så att leverantörer som läser detta vet exakt vad de ska fokusera på.

Här är ett exempel på hur detta kan se ut.

D.1 Utvärderingsmetod

Alla förslag kommer att granskas av ett tvärfunktionellt team som omfattar ekonomi, teknik, efterlevnad och RevOps. Utvärderingen genomförs i tre steg:

• Efterlevnadsgranskning: Bekräfta att alla obligatoriska dokument är närvarande och uppfyller formateringskraven.
  
• Kvalitativ bedömning: Poängsätt varje inlämning mot de viktade kriterierna nedan med hjälp av en skala upp till 1–5 där 5 är exceptionellt och 1 inte når upp till baslinjen.
  
• Demonstration och slutlig granskning: Bjud in utvalda leverantörer till plattformsdemonstrationer live.
  

D.2 Utvärderingskriterier och viktning

Ovanstående vikter kan justeras beroende på projektets prioriteringar, men måste vara totalt 100 %.

D.3 Demonstrationskrav

Leverantörer på slutlistan visar:

• Heltäckande faktureringsflöden i en live-sandlåda med abonnemangsskapande, abonnemangsändringar mitt i cykeln och användningsbaserad fakturagenerering
  
• Införande, aggregering och fakturering av användningsmätningar i realtid
  
• Dunning-konfiguration, ML-återförsökslogik och dashboard för återvinningsrapportering
  
• Genomgång av API-anrop inklusive latens, felhantering och bekräftelse av webhook-leverans
  
• Kundportal och intern dashboard-funktionalitet
  
• Agentiskt handelsscenario (dvs. en AI-agent eller automatiserat arbetsflöde initierar en abonnemangsåtgärd via API)
  

Leverantörer måste ange tillfälliga demoautentiseringsuppgifter som är giltiga i minst 10 arbetsdagar efter demonstrationen.

D.4 Förhandling och kontraktstilldelning

[Your company] förbehåller sig rätten att genomföra förtydligande sessioner, begära bäst-och-slutliga erbjudanden och förhandla med en eller flera leverantörer. Inget avtal är bindande förrän det genomförs av båda parter.

⚑ Utvärderarens anteckningar – ta bort dem innan de skickas till leverantörer ⚑

• Betygsätt självständigt före gruppöverläggning. Motivera varje poäng över 4 eller under 2 med bevis från inlämningen eller demoversionen.
  
• Behandla anspråk på ”standardfunktionalitet” skeptiskt och kräv dokumentation eller en demogenomgång live.
  
• Prioritera leverantörer med dokumenterade resultat för maskininlärning, API-latens under 300 ms vid p99 och sandlådor med produktionsparitet.
  
• Väg kriteriet för agentisk handel högre om din färdplan inkluderar AI-drivna kundresor eller autonom abonnemangshantering.
  
• Flagga varningssignaler som vag prissättning, bristande efterlevnad på nyckelmarknader, sandlåda som saknas och inga publicerade API SLA.
  

Avsnitt E: Grundläggande krav

Det här är det viktigaste avsnittet. Kräv svar som baseras på fakta och bevis. Alla leverantörer som är värda att listas kan peka på produktionsstatistik, publicerad dokumentation och verkliga kundexempel – inte bara påstådda funktioner. För varje krav måste leverantörerna ange någon av följande statusar: Standard (i produktion idag), Konfigurerbar (kräver konfiguration), Anpassat (kräver utveckling) eller N/A.

Här är ett exempel på hur detta kan se ut.

E.1 Sälja och ta emot beställningar

För säljteam

För kassaflödet

En kassaupplevelse som förlorar kunder i betalningssteget är ett faktureringsproblem, inte bara ett UX-problem. Förvänta dig att leverantörerna tillhandahåller dokumenterade konverteringsdata från produktionsmiljöer – inte uppskattningar.

För SaaS-plattformar

För global efterlevnad

Global efterlevnad är ett löpande operativt krav. Standarderna för efterlevnad ändras: PCI DSS v4.0 trädde i kraft i mars 2024 och jurisdiktioner från Indien till Tyskland och Brasilien inför specifika faktureringsskyldigheter. Din leverantör måste spåra och implementera dessa automatiskt, istället för att vänta på att du frågar.

E.2 Hantering av fakturerings och abonnemangslivscykel

Flexibilitet i prismodellen

En faktureringsplattform som endast hanterar fastprisabonnemang begränsar redan din lanseringsstrategi. Användningsbaserad och multiattributprissättning är standard för SaaS- och infrastrukturföretag. Din leverantör behöver stöd för dem internt, inte genom alternativa lösningar.

Automatisering

Det operativa värdet av en faktureringsplattform skalas upp direkt med vad den automatiserar. Manuella ingrepp i faktureringsarbetsflöden är en källa till fel, förseningar och kostnader som kan undvikas.

Användarvänlighet

E.3 Inkassera betalningar och minska kostnaderna

Betalningsmetoder och auktoriseringsresultat

Täckning av betalningsmetoder och auktoriseringsgrad har en direkt påverkan på intäkterna och är inte sekundära eftertankar. En förbättring på 1 % av auktoriseringsgraden för en portfölj med återkommande fakturering är stora pengar. Skillnaden mellan leverantörer beror ofta på nätverkets skala: maskininlärningsbaserad återförsökslogik fungerar bara bra när modellen är tränad på tillräckligt många signaler för att veta vilka parametrar som ska justeras för en viss utfärdare, korttyp och felkod. Stripes Adaptive Acceptance, till exempel, bygger på data från miljontals företag för att finjustera återförsök i realtid. Det är riktmärket man ska hålla andra leverantörer mot. Kräv dokumenterade riktmärken för auktoriseringsgrad från produktionsmiljöer och be leverantörerna förklara specifikt hur de uppnår dem.

Optimering av kostnader

E.4 Behålla kunder och återvinna intäkter

Minskning av ofrivilligt kundbortfall

Misslyckade betalningar är den enskilt största orsaken till ofrivilligt kundbortfall för abonnemangsföretag. Hur en leverantör hanterar betalningsåterhämtning är en kärnkompetens som förtjänar samma granskning som stöd för prismodeller. Stripe Smart Retries, som ingår i Stripe Billing utan extra kostnad, använder maskininlärning för att identifiera den optimala tidpunkten för återförsök per kund, istället för att köra ett fast schema. Nätverkstokens minimerar antalet nekade betalningar ytterligare genom att uppdatera kortuppgifter automatiskt när underliggande uppgifter ändras, utan att kräva några kundåtgärder. När du utvärderar andra leverantörer i det här måttet ska du använda Stripes återvinningsresultat som bas: kräv data om produktionsåtervinningsgrad, fråga hur logiken för återförsök tränas och behandla vaga svar som en signal.

Minska frivilligt kundbortfall

E.5 Agentisk handel och integrerade finansiella funktioner

AI-agenter och automatiserade arbetsflöden initierar i allt högre grad kommersiella transaktioner. De kan schemalägga abonnemangsdebiteringar, svara på kundförfrågningar och hantera faktureringshändelser utan direkta mänskliga åtgärder. Faktureringsinfrastruktur som byggs 2026 måste ta hänsyn till detta. Leverantörer som inte har tänkt på agentisk fakturering kommer att skapa flaskhalsar i integrationen när du skala upp AI-drivna kundupplevelser.

Agentisk handel

Agentisk handel avser AI-agenter eller automatiserade system som initierar, ändrar eller säger upp abonnemang och fakturerar åtgärder för kundernas räkning. Detta kräver API:er och autentiseringsmönster som är specialbyggda för interaktioner mellan maskiner, inte anpassningar av flöden mellan människor.

Inbäddade finansiella produkter

Faktureringsinfrastruktur som ansluter till närliggande finansiella produkter (t.ex. kortutfärdande, kassaförvaltning, utlåning) skapar mervärde för plattformar och marknadsplatser. Om du erbjuder eller planerar att erbjuda finansiella produkter tillsammans med din kärnprodukt är din faktureringsleverantörs förmåga att integrera med dessa produkter viktig.

E.6 Rapportering, analys och intäktsredovisning

Rapportering av företagets resultat

Faktureringsdata är intäktsdata. Din leverantör bör ge dina finans-, RevOps- och ledningsteam insyn i realtid i vad som händer i din abonnentbas, inte CSV-exporter som du avstämmer manuellt i efterhand.

Intäktsredovisning och avstämning

Om ditt team manuellt bygger vattenfallsrapporter för intäkter eller stämmer av faktureringsdata mot din huvudbok är det en lucka som din nästa leverantör bör åtgärda. Efterlevnad av ASC 606 och IFRS 15 bör vara inbyggt, inte bifogas i efterhand.

Hantering av tvister

E.7 API-prestanda och utvecklarupplevelse

En faktureringsplattform som du inte kan integrera på ett tillförlitligt sätt – eller som försämras under belastning – är ett allvarligt problem. Utvärdera API-kvalitet med samma noggrannhet som du tillämpar för funktionstäckning. Be om produktionsprestandadata, inte riktmärken från syntetiska testmiljöer.

API-prestanda

Utvecklarupplevelsen

Integrationer

E.8 Säkerhet, efterlevnad och datasekretess

Efterlevnad är ett rörligt mål. PCI DSS v4.0 trädde i kraft i mars 2024 och införde nya krav på autentisering, övervakning och riktad riskanalys. Tillämpningen av GDPR har intensifierats sedan 2023, och tillsynsmyndigheter delar ut rekordböter för överträdelser av datahanteringen. Din leverantör måste hålla sig uppdaterad, inte jobba på att komma ikapp.

E.9 Skalbarhet och tillförlitlighet

E.10 Intyg om leverantörscertifiering

Jag intygar härmed att alla svar är korrekta på inlämningsdatumet och att funktioner märkta Standard eller Konfigurerbara för närvarande är tillgängliga i produktionsmiljöer. Anspråk som inte stöds av dokumentation eller en live-demonstration kommer inte att utvärderas.

Auktoriserat ombud: ________________________
Titel: ________________________
Datum: ________

⚑ Utvärderarens anteckningar – ta bort dem innan de skickas till leverantörer ⚑

• Kräv kvantitativa bevis för alla prestationsanspråk, t.ex. återvinningsgrad, auktoriseringsgrad och API-latensriktmärken, samt siffror för upptid.
  
• Validera anspråk på API-prestanda i sandlådedemo – mät den faktiska latensen, inte siffror från leverantörer.
  
• Flagga alla leverantörer som inte kan visa scenarier för agentisk fakturering i en sandlåda.
  
• Behandla saknat stöd för ASC 606 eller sandlåda utan produktionsparitet som diskvalificering för faktureringsmogna företag.
  
• Verifiera efterlevnaden av PCI DSS v4.0 i enlighet med version 3.2.1 som upphörde den 31 mars 2024.
  

E.11 Hur hanterar Stripe dessa krav?

Om du utvärderar Stripe som din faktureringspartner kan du läsa mer om hur vår plattform matchar kraven i avsnitt E. Vi har grupperat våra funktioner efter de områden där de underliggande arkitekturbesluten har störst inverkan på ditt företag.

Flexibilitet i abonnemangs- och prismodeller

Stripe Billing stöder mer än 15 prismodeller – fasta, nivåbaserade, volymbaserade, graderade, användningsbaserade, multiattributbaserade och hybridkombinationer – utan att det krävs anpassat tekniskt arbete för varje marknadslansering. Användningsbaserad fakturering, inklusive stöd för upp till 100 miljoner användningshändelser per månad, hanterar mätning av alla attribut som du definierar: API-anrop, databehandling, resultat, licenser eller anpassade mått. Stripes förvärv av Metronome, som nu är en Stripe-produkt, utökar detta ytterligare för företag som har komplexa storföretagsavtal med förbetalda och efterbetalda åtaganden, ändringar i betalningscykeln och anpassade rabatter. Nya prismodeller kan lanseras direkt från Dashboard med kodfria priskort, med uppdateringar som skickas direkt till din abonnentbas. För fullständig dokumentation, se Stripe Billing och användningsbaserad fakturering.

Betalningsåtervinning

Misslyckade betalningar är den största orsaken till ofrivilligt kundbortfall för abonnemangsföretag, och faktureringsplattformar uppvisar tydliga skillnader när det gäller återvinningsresultat. Stripes Smart Retries använder maskininlärning för att fastställa den optimala tidpunkten för nya försök per kund – med hjälp av signaler från Stripes nätverk – istället för att köra en statisk kalender för återförsök. Stöd för nätverkstokens innebär att när en kunds underliggande kortinformation ändras uppdaterar Stripe en token automatiskt, vilket minimerar antalet nekade betalningar utan att kunden behöver göra något. Den automatiska kortuppdateraren täcker Visa, Mastercard, Amex och Discover och körs i bakgrunden på alla aktiva abonnemang. Smart Retries och dunning-hantering ingår utan extra kostnad i Stripe Billing. Se Stripes dokumentation för dokumentation om intäktsåtervinning.

Global skatt och efterlevnad

Stripe Tax beräknar omsättningsskatt, moms och GST i mer än 100 länder och 600 produktkategorier och uppdateras i realtid när skattesatserna ändras, med en dokumenterad historisk upptid på 99,999 %. Täckningen omfattar modeller för B2B, B2C, abonnemang och marknadsplatser så att du kan expandera till nya marknader utan att behöva bygga om din skattelogik varje gång. Inkassering av skatt kan aktiveras i en ny jurisdiktion på några sekunder från Dashboard – eller med en enda rad kod – och Stripe Tax integreras med deklarationspartner för att hantera överföringar där det stöds. För aktuell dokumentation om jurisdiktionstäckning och efterlevnad, se Stripe Tax.

Intäktersrapportering och -redovisning

Stripe Revenue Recognition automatiserar periodiserad redovisning i enlighet med ASC 606 och IFRS 15 och genererar vattenfallsdiagram över intäkter, scheman för förutbetalda intäkter och bokföringsposter direkt från dina faktureringsdata – utan att det krävs någon manuell avstämning. Varje redovisat och förutbetalt belopp kan spåras tillbaka till den underliggande kunden och fakturan, vilket gör revisionerna betydligt snabbare. För team som behöver anpassad SQL-åtkomst till sina faktureringsdata tillhandahåller Stripe Sigma en interaktiv miljö för frågor i Dashboard. Stripe Data Pipeline synkroniserar dina Stripe-data med Snowflake, BigQuery eller Redshift för lagerbaserad analys, där åtkomst till Sigma ingår. För mer information, se Stripe Revenue Recognition och Stripe Data Pipeline.

API och utvecklarupplevelse

Stripes RESTful API levereras med SDK:er på serversidan för Node.js, Python, Ruby, Java, Go, PHP och .NET, plus mobila SDK:er för iOS och Android. API:et versionsbenämns efter lanseringsdatum, med meddelanden om nedläggning som förannonseras i SDK README-filerna och ändringsloggen, och ett utökat supportfönster på ett till två år per språkversion efter upphörande. Stripes sandlådemiljö – som nu kallas Sandboxes – ger full produktionsparitet för alla faktureringsflöden, inklusive användningsmätning, dunning-hantering och intäktsredovisning, utan begränsningar i testläget för frågevolym. Stripes genomsnittliga upptid på 90 dagar mäts med fem nior. För referensmaterial för API, SDK-dokumentation och åtkomst till sandlådor, se Stripes dokumentation.

Agentisk handel

Stripe har byggt för agentisk fakturering sedan innan de flesta leverantörer nämnde kategorin. Agentic Commerce Protocol (ACP), som utvecklats tillsammans med OpenAI och finns i ChatGPT:s Instant Checkout, erbjuder en öppen standard där AI-agenter kan initiera och slutföra transaktioner programmatiskt. Stripes Shared Payment Tokens gör det möjligt för agenter att agera på uppdrag av köpare med tidsbegränsade autentiseringsuppgifter inom omfattningen som aldrig avslöjar underliggande kortinformation – med fullständig granskningsloggning och webhook-händelser för varje åtgärd. För abonnemangsföretag stöder Stripe Billings API-design arbetsflöden direkt från maskin till maskin: agenter kan skapa, ändra och säga upp abonnemang med hjälp av detaljerade begränsade API-nycklar med behörigheter som omfattningsbestäms exakt efter vad varje agent behöver. Stripe Agent Toolkit och Stripe MCP-server ger utvecklare färdiga integrationer med ramverk som LangChain, OpenAI:s Agents SDK och CrewAI. För dokumentation, se Stripes agentiska handel och Stripe MCP.

Om du vill se någon av dessa funktioner i livemiljö kan du kontakta Stripes säljare för att arrangera en sandlådedemo eller besöka Stripes dokumentation för fullständig teknisk dokumentation.

Avsnitt F: Implementering och support

Den bästa faktureringsplattformen kan misslyckas om implementeringen inte går smidigt. I det här avsnittet undersöker vi om leverantören har den metodik, de resurser och den supportmodell som krävs för att få dig live utan att störa din faktureringsverksamhet och se till att du fortsätter att fungera tillförlitligt efteråt.

Här är ett exempel på hur detta kan se ut.

F.1 Implementeringsmetod och tidslinje

Leverantörer måste beskriva:

• Ramverk för projektledning (agilt, vattenfallsbaserat eller hybridbaserat) och hur framsteg spåras och rapporteras till kunden
  
• Typisk lanseringstid för kunder av jämförbar skala och priskomplexitet
  
• Hur risker förknippade med integration – särskilt med CRM-, ERP- och datalagersystem – identifieras och minskas
  
• Hur en parallell faktureringskörning eller cutover-strategi skyddar intäkternas kontinuitet under migrationen
  

F.2 Resurser och styrning

Leverantörer ska tillhandahålla:

• Organisationsschema eller RACI-diagram för implementeringsteamet
  
• Bekräftelse av om nyckelrollerna är interna eller underleverantörer
  
• Namngiven kontoansvarig och lösningsarkitekt som tilldelats detta uppdrag
  
• Eskaleringshierarki och beslutsfrekvens
  

F.3 Utbildning och kunskapsöverföring

Leverantörerna ska beskriva:

• Utbildning tillgänglig för ekonomi, RevOps, teknik och kundframgång
  
• Tillgänglig utbildning on demand, dokumentation och certifieringsvägar
  
• Hur de håller utbildningsmaterialet aktuellt med nya produktlanseringar
  

F.4 Supportmodell och servicenivåer

Leverantörer måste ange:

• Supportnivåer och vad som ingår på varje
  
• Tillgänglig support dygnet runt för större faktureringstillbud – ett faktureringsavbrott innebär tappade intäkter
  
• SLA:er för svarstid efter allvarlighetsgrad
  
• Hur kunder meddelas i realtid vid incidenter
  
• Tidigare resultat för upptid med ett minimimål på 99,9 % och en preferens på minst 99,99 %
  

F.5 Underhåll och uppgraderingar

Leverantörer bör förklara:

• Hur produktlanseringar kommuniceras (t.ex. versionsmeddelanden, ändringsloggar, aviseringsperioder)
  
• Policy för versionshantering och avveckling av API:er (minst 12 månaders förhandsmeddelande för att brytande ändringar)
  
• Huruvida uppgraderingar kan implementeras utan faktureringsavbrott
  

F.6 Kontinuerlig förbättring

Beskriv hur du använder plattformsanalys, maskininlärningsdriven insikt och proaktiv övervakning för att förbättra faktureringsresultat över tid. Ge specifika exempel på mätbara förbättringar som levereras till befintliga kunder, till exempel ökad återvinningsgrad, bättre auktoriseringsgrad och färre faktureringsrelaterade supportärenden.

F.7 Intygande från leverantör

Jag intygar att alla uppgifter om implementering och support som tillhandahålls här är korrekta per inlämningsdatumet och återspeglar aktuella produktionsmetoder och servicenivåer.

Auktoriserat ombud: ________________________
Titel: ________________________
Datum: ________

⚑ Utvärderarens anteckningar – ta bort dem innan de skickas till leverantörer ⚑

• Validera åtaganden om tidslinjen mot jämförbara åtaganden. Be om specifika exempel, inte intervall.
  
• Bekräfta att support dygnet runt stämmer. Begär exempel på svarstider vid större incidenter på senare tid.
  
• Fråga om implementeringsteamet är samma team som hanterar support efter lansering.
  
• Kräv en skriftlig policy för nedläggning av API:er innan avtalet undertecknas.
  

Avsnitt G: Kommersiellt

Faktureringsplattformspriser kan vara otydliga. I det här avsnittet standardiseras hur leverantörer presenterar kostnader så att du kan jämföra dem på rätt sätt. Om du inte kräver specificerad information i förväg kommer du att upptäcka paketerade avgifter och minimiåtaganden först efter att avtalet har undertecknats.

Här är ett exempel på hur detta kan se ut.

G.1 Översikt över prisstruktur

Leverantörer måste tillhandahålla:

• Detaljerad prissättning för alla komponenter, inklusive plattformsavgifter, avgifter per transaktion, användning och tillägg
  
• Ett narrativ som förklarar antaganden om prissättning som volymnivåer, valutor och uppskattningar av faktureringshändelser
  
• Tydlig identifiering av eventuella månatliga minimiåtaganden eller tröskelpriser
  
• Alla siffror i USD (inklusive växlingslogik om de anger andra valutor)
  

G.2 Priskomponenter

G.3 Volymnivåer

Tillhandahåll en känslighetsanalys som visar hur priserna ändras vid följande volymer.

G.4 Avtalsvillkor och flexibilitet

• Tillgängliga avtalslöptider och tillhörande prisincitament
  
• Huruvida priserna skalas ner automatiskt om volymen minskar
  
• Omförhandlingsprocess för flerårsavtal
  
• Minimikrav för utgifter
  
• Utträdesklausuler och villkor för dataportabilitet (dvs. hur returneras dina data, i vilket format och på vilken tidslinje?)
  

G.5 Antaganden och beroenden

Lista alla kommersiella antaganden som ligger till grund för din prissättning, inklusive volymminimibelopp, exklusivitetskrav, specifika betalningsmetoder och geografisk omfattning. Ej angivna antaganden som upptäcks efter att avtalet har genomförts kan behandlas som en väsentlig felaktig framställning.

G.6 Leverantörscertifiering

Jag intygar att priserna och de kommersiella uppgifterna i detta förslag är fullständiga och korrekta på inlämningsdatumet och återspeglar alla tillämpliga rabatter, avgifter och villkor.

Auktoriserat ombud: ________________________
Datum: ________

⚑ Utvärderarens anteckningar – ta bort dem innan de skickas till leverantörer ⚑

• Stäm av alla siffror mot Excel-prislistan – avvikelser är ett varningstecken
  
• Se upp för kombinerade avgifter som döljer enhetskostnader, särskilt för hantering av mätning och dunning.
  
• Utvärdera villkoren för dataportabilitet noggrant. Inlåsning sker ofta i datalagret, inte i avtalslagret.
  
• Flagga alla leverantörer som inte kan tillhandahålla volymkänslighetsanalys.
  

Avsnitt H: Leverantörsprofil

En faktureringsplattform är en långsiktig infrastrukturpartner. Du måste känna till företaget bakom produkten – dess ekonomiska hälsa, tekniska djup och utveckling – inte bara om dagens funktionslista ser rätt ut.

Här är ett exempel på hur detta kan se ut.

H.1 Företagsöversikt

Ge en sammanfattning i två till tre stycken som täcker din historik, mission och marknadsposition. Betona din erfarenhet av att stödja fakturering i storföretagsskala, fakturering på flera marknader och dina meriter för att upprätthålla efterlevnad i takt med att regelverken utvecklas.

H.2 Ledarskap och nyckelpersoner

Inkludera kortfattad information (tre till fem rader) om de viktigaste ledarna som är involverade i detta engagemang. Beskriv deras expertis inom teknik eller efterlevnad och eventuella relevanta certifieringar.

H.3 Finansiell stabilitet

Tillhandahåll reviderade finansiella rapporter eller motsvarande bevis på solvens. Privata företag bör tillhandahålla CFO-brev som intygar likviditet. Beskriv din finansieringsstruktur, om tillämpligt.

H.4 Certifieringar och efterlevnad

H.5 Produktfärdplan

Tillhandahåll en färdplan på hög nivå som täcker kommande versioner under de kommande 12–18 månaderna. Lyft fram planerade investeringar i maskininlärningsbaserade funktioner, support för agentisk handel, global efterlevnadstäckning och API-prestanda. Förklara hur kundfeedback påverkar din prioritering.

H.6 Partnerskap och system

Lista viktig teknik och kanalpartnerskap som är relevanta för detta engagemang. Beskriv hur dessa förbättrar tillförlitligheten, efterlevnadstäckningen eller integrationsdjupet.

H.7 Miljö- och hållbarhetspraxis

Beskriv metoder som minskar miljöpåverkan (t.ex. digitala kvitton som standard, pappersfri fakturering, insikt i betalningsmetoders miljöpåverkan). Förklara hur hållbarhet är inbäddat i din plattformsverksamhet.

H.8 Leverantörens försäkran om riktighet

Jag intygar att all information i avsnitt H är korrekt per inlämningsdatumet och att [vendor] har den finansiella, tekniska och operativa kapaciteten att utföra de beskrivna tjänsterna.

Auktoriserat ombud: ________________________
Datum: ________

Avsnitt I: Referenser

Referenser från jämförbara kunder berättar mer än någon demo kan göra. Prioritera referenser som liknar ditt företag med liknande priskomplexitet, skala och regulatorisk miljö. Generiska referenser från olika vertikaler eller mycket mindre företag förutspår inte din upplevelse.

Här är ett exempel på hur detta kan se ut.

I.1 Referenskrav

Leverantörer måste ange minst tre klient som uppfyller dessa kriterier:

• Jämförbar faktureringsvolym med [your company]
  
• Liknande komplexitet i prismodellen (användningsbaserad eller prissättning med flera attribut föredras)
  
• Överlappande geografiskt och regulatoriskt fotavtryck
  
• Aktiv kund i produktion i minst 12 månader
  

I.2 Referenstabell

I.3 Sammanfattning av referensresultat

Ange mätbara resultat för varje referens, t.ex. förbättrad betalningsåterhämtning, ändring i auktoriseringsgrad, tidslinje för implementering och automatisering av intäktsredovisning. Inkludera kundomdömen om tillämpligt.

I.4 Referensvalidering

Jag intygar att varje kund har samtyckt till att agera som referens och att all information som tillhandahålls är korrekt.

Auktoriserat ombud: ________________________
Datum: ________

⚑ Utvärderarens anteckningar – ta bort dem innan de skickas till leverantörer

• Ring minst två referenser per telefon – skriftliga sammanfattningar är sammanställda.
  
• Fråga specifikt om implementeringsupplevelsen och vad som gick fel, inte bara plattformen i steady state.
  
• Fråga referenser om leverantörens anspråk på maskininlärningsåtervinning har stått sig i produktionen.
  
• Flagga generiska, ej verifierbara eller tydligt felmatchade referenser.
  

Avsnitt J: Bilagor

J.1 Checklista för inlämning (används av leverantör)

Bifoga som första sida i ditt svarspaket. Ofullständiga inlämningar kan uteslutas från utvärderingen.

J.2 Ordlista för termer

J.3 Bedömningsmatris (internt bruk)

Beräkna följande för varje leverantör:

• Fakturering (25 %)
  
• API (15 %)
  
• Återvinning (15 %)
  
• Efterlevnad (15 %)
  
• Rapportering (10 %)
  
• Agentisk (5 %)
  
• Support (5 %)
  
• Kommersiellt (10 %)
  
• Viktad totalsumma
  

J.4 Snabbreferenslista för faktureringskrav

En kortfattad checklista för självbedömning av leverantörer innan de skickar in.

Sälja och ta emot beställningar

• CRM-integration för att skapa offerter
  
• Konvertering av offert till abonnemang och offert till faktura
  
• Offerter i flera valutor
  
• Webb, mobil och fysisk kassa
  
• Sparade inloggningsuppgifter eller Link-motsvarighet för återkommande kunder
  
• Identifiering av bedrägerier med låg andel falska nekade betalningar
  
• 3DS2 med hantering av PSD2-undantag
  
• Stöd för medgivande av ACH, SEPA, förhandsgodkänd debitering och Bacs
  
• Efterlevnad av RBI-medgivande
  
• Kündigungsbutton i Tyskland för uppsägning med ett klick
  
• Lokalt kompatibla fakturamallar, inklusive Brasiliens Nota Fiscal
  
• OFAC- och sanktionskontroller
  

Fakturerings- och prenumerationshantering

• Fast, nivåbaserad, volymbaserad och graderad prissättning
  
• Användningsbaserad fakturering med konfigurerbar aggregering
  
• Multiattributprissättning (licenser och användning)
  
• Hantering av behörigheter för funktioner
  
• Gratis provperioder, förskottsbetalning och delbetalningar
  
• Automatiserad skatteberäkning för omsättningsskatt och moms
  
• Proportionell fördelningslogik
  
• Massändringar av abonnemang och hierarkiska konton
  
• Självbetjäningsportaler för kunder
  

Betalningar, återvinning och auktorisering

• Kort, plånböcker, bankdebiteringar och banköverföringar
  
• Stöd för nätverkstokens för förbättring av återkommande auktorisering
  
• ML-driven dunning-hantering med dynamiska återförsök (Adaptive Acceptance eller motsvarande)
  
• Automatisk kortuppdatering
  
• Prediktivt återförsök med dokumenterad återvinningsgrad
  
• Lokala inlösare
  
• Data på nivå II eller III och överföring av AVS- eller postnummer
  
• Optimering av FX-avgifter
  

Agentiska och inbäddade funktioner

• API-autentisering från maskin till maskin för fakturering initierad av agent
  
• Granulära API-behörigheter eller OAuth-omfattningar
  
• Verifieringskedja för agentinitierade åtgärder
  
• Kortutfärdande och kassaförvaltingsintegration
  
• Köp nu, betala senare eller finansiering i kassan
  

Rapportering och intäktsredovisning

• Dashboards i realtid för MRR, ARR, kundbortfall och NRR
  
• Återvinningseffektivitet och avledningsrapportering
  
• Anslutning till datalager
  
• Intäktsredovisning enligt ASC 606 och IFRS 15
  
• Vattenfallsdiagram över intäkter och förutbetalda intäkter
  
• Integration av ERP- och redovisningssystem
  
• AI-drivna intäktsprognoser
  

API, säkerhet och teknisk

• API-latens under 300 ms vid p99, dokumenterad från produktion
  
• SLA med minst 99,9 % upptid och historiska data
  
• Komplett sandlåda med produktionsparitet
  
• Versionsbaserat API med 12 månaders varsel om nedläggning
  
• PCI DSS v4.0 (mars 2024)
  
• SOC 2 typ II
  
• GDPR- och CCPA-datasekretesskontroller
  
• Alternativ för datahemvist
  

J.5 Certifiering av leverantörsinlämning

Jag intygar att denna inlämning är fullständig och att all information som tillhandahålls är korrekt så vitt jag vet. Jag intygar att [your company] förbehåller rätten att kontrollera eventuella anspråk i detta svar.

Företagsnamn: ________________________
Auktoriserat ombud: ________________________
Titel: ________________________
Namnteckning: ________________________
Datum: ________