Has llançat un producte d'API mesurada. Els clients carreguen 500 $ en crèdits, els consumeixen durant sis setmanes fent crides al teu punt de connexió, i tu cobres per avançat. Senzill, oi? Llavors el teu comptable pregunta: "Quants ingressos vas obtenir realment al març?"
Si la teva resposta és "500 $, perquè això és el que va ingressar al compte bancari", tens un problema, i no és petit. La facturació basada en l'ús i el consum s'ha convertit en l'estàndard per a productes d'API, eines d'IA i startups d'infraestructura, però les normes comptables per reconèixer aquests ingressos no s'han tornat més senzilles només perquè el model de facturació s'ha tornat més flexible. Fer-ho malament no només significa presentar impostos incorrectament, sinó que també estàs interpretant malament la teva pista de vol, enganyant els inversors i preparant-te per a una dolorosa reexpressió més endavant.
Aquí tens el que realment regeix això i com construir els teus llibres perquè els números siguin correctes des del primer moment.
Per què "Diners Entrants" no Significa "Ingressos Obtinguts"
Segons els principis comptables generalment acceptats dels EUA (US GAAP), el reconeixement d'ingressos està regulat per l' ASC 606, un marc de cinc passos:
- Identificar el contracte amb un client
- Identificar les obligacions de rendiment del contracte
- Determinar el preu de la transacció
- Assignar el preu de la transacció a les obligacions de rendiment
- Reconèixer els ingressos quan (o a mesura que) es satisfà cada obligació de rendiment
Per a una subscripció anual de tarifa plana, això és fàcil: els ingressos es distribueixen de manera uniforme al llarg de 12 mesos independentment de quan es va pagar la factura. Per a la facturació basada en l'ús, el pas 5 és on les coses es tornen realment complicades: reconèixes els ingressos a mesura que el client consumeix el servei, no quan et paga.
Aquesta única frase és l'arrel de gairebé tots els errors comptables basats en l'ús. Un client que prepaga 500 d'ingressos: t'ha donat 500 $ en efectiu i un passiu. Li deus o el servei o la devolució dels diners. Només a mesura que consumeixin crides, emmagatzematge o càlcul, podràs traslladar aquest passiu a ingressos reconeguts.
L'Obligació de Disponibilitat Permanent, Explicada de Manera Senzilla
Els comptables tenen un terme per al que realment estàs venent en un model basat en l'ús: una obligació de disponibilitat permanent. No només promets processar crides d'API, sinó que promets estar disponible per processar-les sota demanda, sempre que el client vulgui, fins al volum que necessiti.
Això és important perquè pot dividir els teus ingressos en dues peces conceptualment diferents:
- Component d'accés: el valor de simplement estar disponible (de vegades es reconeix linealment durant el període del contracte)
- Component de consum: el valor lliurat per unitat d'ús real (es reconeix a mesura que es produeix l'ús)
La majoria de productes de pagament pur per crida (sense tarifa base ni compromís mínim) redueixen això al component de consum, cosa que és una bona notícia perquè és el cas més senzill de comptabilitzar.
Contraprestació Variable: Per què no Pots Simplement Esperar i Veure
Com que l'import final de la factura depèn de l'ús que ningú pot predir en el moment de signar el contracte, l'ASC 606 tracta les tarifes basades en l'ús com a contraprestació variable. En teoria, això vol dir que hauries de estimar el preu de la transacció inicialment, utilitzant:
- El mètode del valor esperat: una mitjana ponderada per probabilitat dels resultats possibles, o
- El mètode de l'import més probable: la teva única millor estimació
I, críticament, només pots incloure una estimació als teus ingressos reconeguts en la mesura que no es produirà una reversió significativa més tard un cop es conegui l'ús real. Aquesta "restricció" existeix específicament per evitar que les empreses registrin ingressos optimistes d'hora i hagin de retrocedir-los després, un patró que els reguladors han assenyalat repetidament en audits de programari.
Per a un desenvolupador independent que funciona amb pocs recursos, construir previsions d'ús ponderades per probabilitat cada mes és excessiu. Per sort, hi ha una drecera.
L'Expedient Pràctic Que Gairebé Tota Empresa d'API Hauria d'Utilitzar
L'ASC 606 inclou un expedient pràctic de "dret a facturar": si l'import que tens dret a facturar en un període determinat es correspon directament amb el valor que has lliurat en aquell període, pots ometre l'exercici d'estimació i simplement reconèixer els ingressos a mesura que es produeix l'ús, per l'import que tens dret a facturar.
Aquest és el patró estàndard per a preus purs per crida, per testimoni o per transacció: si cobres 0,001 $ per crida d'API sense descomptes per volum ni compromisos mínims, l'import que pots facturar per les crides d'un dia determinat és el valor lliurat aquell dia. No cal estimació: reconeixes els ingressos a mesura que es produeixen les crides, punt.
On l'expedient es trenca són els preus per trams o per volum acumulatiu, on la tarifa per unitat del segon període depèn de quant va utilitzar el client al primer període (pensa: "primeres 100.000 crides a 0,002 "). En aquest cas, l'import facturat en un sol període no es correspon clarament amb el valor d'aquell període, i pot ser que necessitis una estimació adequada. Si els teus preus tenen trams de volum, val la pena parlar-ne amb un comptable abans de donar per fet que s'aplica la drecera.
Un Exemple Concret
Suposem que el teu producte d'API té una tarifa base de 200 /crida, amb la mateixa tarifa efectiva que les crides incloses:
- Base + ús inclòs: com que la tarifa d'excés coincideix amb la tarifa inclosa efectiva, tota la tarifa (base més excedents) normalment compleix els requisits per a l'expedient pràctic de la factura. Reconeixes 200 per crida d'excés a mesura que es produeix.
- Paquets de crèdit prepagats: un client compra 1.000 . A mesura que consumeixen crèdits al febrer a 0,002 de crèdits sense utilitzar a finals de mes, 300 $ romanen com a passiu al teu balanç de situació, no com a ingressos, per molt bo que sembli el març.
- Ús no facturat a finals de mes: el teu cicle de facturació va del dia 1 al dia 1, però l'ús d'un client al desembre no es factura fins al 2 de gener. Aquest buit encara necessita un assentament comptable: carrega comptes a cobrar no facturats (un actiu), abona ingressos, pel valor de les crides fetes al desembre però encara no facturades. Quan la factura es lliura realment, es reclasifica de comptes a cobrar no facturats a comptes a cobrar estàndard: els ingressos ja estaven registrats.
Impostos en Base de Caixa vs. Llibres en Base de Meritori
Aquí és on molts fundadors en solitari s'emboliquen: la teva declaració d'impostos i el teu reconeixement d'ingressos no han de funcionar amb la mateixa base, i sovint no haurien de fer-ho. La majoria de petites empreses poden presentar impostos en base de caixa: els ingressos són imposables quan es reben, les despeses deduïbles quan es paguen, independentment del que digui l'ASC 606 sobre quan els ingressos són "obtinguts". Una LLC d'un sol membre que ven crèdits d'API pot pagar legítimament impostos sobre el prepagament de 1.000 com a ingressos reconeguts i 300 $ com a ingressos diferits.
El parany és tractar aquestes dues visions com a intercanviables i mantenir només un conjunt de números. Si només fas un seguiment dels totals en base de caixa, no tindràs una resposta defensable quan un possible comprador, inversor o prestador demani els ingressos en base GAAP durant la diligència debuda, i llavors serà massa tard per reconstruir mesos d'historial d'ús. Mantingues ambdues visions al teu llibre major des del principi: un flux d'efectiu que puguis lliurar al teu preparador d'impostos i una visió de meritació amb ingressos diferits i comptes a cobrar no facturats explícitament seguits, perquè qualsevol pregunta pugui respondre's des de la mateixa font de veritat en lloc d'un full de càlcul creat sota pressió de terminis.
Els Errors Que Realment Fan Mal
Parlant amb equips que han passat per això, els fracassos s'agrupen al voltant d'un grapat de patrons repetibles:
- Deriva de la mesura. Si el teu pipeline de seguiment d'ús infracompta o sobrecompta les crides en relació amb el que realment factures, el teu llibre major d'ingressos i el teu sistema de facturació divergeixen silenciosament, i ningú se n'adona fins a la conciliació, que per a un equip autofinançat podria ser "quan el comptable pregunti per què els números no coincideixen".
- Canvis de pla a mig cicle sense lògica de prorrateig. Un client millora de nivell el dia 15 d'un cicle de 30 dies. Si el teu sistema no divideix l'ús i el preu d'aquest període correctament, reconeixeràs en excés o per defecte els ingressos per a aquell client aquell mes.
- Cap separació entre la lògica de facturació i la lògica de reconeixement d'ingressos. És temptador tractar "el que vam facturar" com "el que vam guanyar". Per a subscripcions planes, aquests números convergeixen ràpidament. Per a preus basats en l'ús, sovint no ho fan, especialment amb crèdits prepagats o mínims anuals.
- Tractar les disputes i els crèdits com una idea tardana. Si un client disputa un càrrec per excés i emets un crèdit, aquest crèdit ha de tornar a fluir pel teu llibre major d'ingressos, no només pel teu sistema de facturació, o inflaràs els ingressos d'un període que des d'aleshores has revertit.
Construir Això als Teus Llibres Des del Primer Dia
Res d'això requereix programari comptable empresarial quan ets petit. El que requereix és tractar els teus esdeveniments d'ús com un artifacte comptable real, no només una entrada de facturació:
- Mantingues un registre auditable d'esdeveniments d'ús (marca de temps, quantitat, tarifa aplicada) separat del teu sistema de facturació: el necessitaràs per reconstruir els ingressos per període i per defensar els números si mai et fan una auditoria o estàs recaptant una ronda de finançament.
- Fes un seguiment dels ingressos diferits i dels comptes a cobrar no facturats com a comptes de llibre major explícits, no suposicions implícites. Si un client ha pagat per avançat i no ho ha utilitzat tot, aquest saldo ha de ser visible als teus llibres, no enterrat en un tauler de facturació que ningú excepte vendes mira.
- Concilia el teu sistema de facturació amb el teu llibre major d'ingressos amb una periodicitat determinada, com a mínim mensualment, perquè la deriva de la mesura es detecti en setmanes, no en trimestres.
Aquest és exactament el tipus d'estructura en què la comptabilitat en text pla i controlada per versions és bona. Quan el teu pla de comptes viu en un llibre major seguit amb Git en lloc d'un tauler SaaS de caixa negra, "mostra'm els ingressos diferits a 1 de març" i "mostra'm totes les entrades d'ingressos basats en l'ús per a aquest client des de l'alta" són només consultes a un fitxer que realment pots llegir, no un tiquet de suport al teu proveïdor de facturació.
Mantingues Honestos els Teus Ingressos Basats en l'Ús
Els preus basats en l'ús són realment millors per als clients i sovint millors per al creixement, però afegeixen una complexitat comptable real als fundadors que preferirien estar llançant productes. Beancount.io et proporciona una comptabilitat de text pla i de doble entrada que fa que els ingressos diferits, els comptes a cobrar no facturats i el reconeixement basat en l'ús siguin transparents i auditables en lloc d'amagar-se dins del SaaS d'un altre. Comença de manera gratuïta i mantingues els teus llibres tan precisos com el teu pipeline de mesura.