Comptabilitat per a desenvolupadors d'extensions de Chrome: reconciliar els pagaments després que Google eliminés els pagaments dins l'aplicació

Obriu avui el tauler de desenvolupador de la Chrome Web Store i notareu que hi falta alguna cosa: una pestanya de "pagaments". Google va tancar el seu propi sistema de pagaments dins l'aplicació per a extensions l'any 2021, i mai ha tornat. Si voleu cobrar per una extensió de Chrome el 2026, esteu sols pel que fa a la facturació, les subscripcions, els reemborsaments, la recaptació d'impostos i —la part que gairebé ningú preveu— la conciliació entre allò que realment ha arribat al vostre compte bancari i allò que heu venut.

Aquest darrer punt fa ensopegar més desenvolupadors independents que la fixació de preus. Un negoci d'un sol desenvolupador que gestiona tres o quatre extensions mitjançant Stripe, Paddle o un embolcall com ExtensionPay acaba tenint dipòsits de pagament que no es corresponen clarament amb cap producte concret, pics de reemborsaments que apareixen del no-res després d'un retard en la revisió de la Chrome Web Store, i un saldo bancari que mai coincideix exactament amb el que el tauler de vendes diu que hauria de ser. Res d'això és un error del vostre negoci. És el resultat previsible d'haver de muntar vosaltres mateixos una pila de pagaments que abans gestionava Google.

Vet aquí com construir una comptabilitat que hi sobrevisqui.

Per què Google es va retirar del negoci dels pagaments​

Els pagaments de la Chrome Web Store es van llançar a principis de la dècada del 2010, quan no hi havia gaires bones opcions perquè un desenvolupador en solitari cobrés per una extensió de navegador. Cap al 2021, Stripe, Braintree i una onada de serveis de "comerciant registrat" (merchant of record) havien madurat prou perquè Google decidís que ja no necessitava gestionar el seu propi sistema de compra, claus de llicència i pagaments. Va discontinuar els pagaments de la Chrome Web Store i va obligar totes les extensions de pagament a triar entre passar a ser gratuïtes o canviar a un processador extern.

El resultat pràctic per als desenvolupadors: cada dòlar que guanya una extensió ara flueix a través d'una pila de pagaments que heu muntat vosaltres mateixos, i cada problema de conciliació que genera aquesta pila us toca resoldre'l a vosaltres. Ja no existeix un únic "informe de pagaments de la Chrome Web Store"; hi ha allò que us dona el vostre processador, més allò que mostren les pròpies analítiques de la fitxa de la Chrome Web Store, més el vostre extracte bancari, i aquestes tres coses rarament coincideixen a la primera ullada.

Processador de pagaments o comerciant registrat: trieu-ne un per extensió​

Abans fins i tot de començar la conciliació, cal saber a quin costat de la transacció us trobeu legalment, perquè això canvia allò que acaba als vostres llibres.

Un processador de pagaments (Stripe directament, o un embolcall construït al seu damunt com ExtensionPay) us converteix a vosaltres en el venedor. Vosaltres cobreu els diners, sou el comerciant registrat a efectes fiscals, i sou responsables de determinar les obligacions d'impost sobre vendes i d'IVA a cada jurisdicció on visqui un client. Les comissions són més baixes —la tarifa base de Stripe és del 2.9% + $0.30 per càrrec, i un embolcall com ExtensionPay normalment hi afegeix la seva pròpia comissió— però la càrrega de compliment normatiu recau sobre vosaltres.

Un comerciant registrat (Merchant of Record) (Paddle, Lemon Squeezy, Fungies i similars) esdevé legalment el venedor en lloc vostre. Recapten l'IVA o el GST, presenten les declaracions en els més de 140 països que ara ho exigeixen per als béns digitals, gestionen els contracàrrecs i us paguen els ingressos nets. Cediu un 4–8% dels ingressos en lloc d'aproximadament un 3%, però desapareix tota una categoria de feina comptable i de presentació d'impostos. Per a un desglossament complet dels compromisos i com fer els càlculs de quan el canvi val la pena, consulteu la nostra guia de comerciant registrat.

Per a la majoria de desenvolupadors independents d'extensions amb ingressos per sota d'uns pocs milers de dòlars al mes, el 3–5% addicional que cobra un MoR és una assegurança barata per evitar haver de registrar-vos per a l'IVA a una dotzena de països a mà. Un cop tingueu ingressos recurrents reals repartits entre diverses extensions, torneu a fer la comparació: els números canvien a mesura que creix el volum.

Sigui quina sigui la vostra opció, deixeu-ho per escrit. Els vostres llibres necessiten una resposta clara a "qui és el venedor legal registrat d'aquesta extensió", perquè això determina si el passiu per impost sobre vendes apareix o no al vostre balanç.

El problema de la conciliació és estructural, no un error​

Aquí ve la part que agafa desprevinguts els desenvolupadors: fins i tot amb un processador ben configurat, el pagament que rebeu gairebé mai és igual als ingressos que vau generar en aquell període. Tres coses trenquen la correspondència 1:1:

• Pagaments per lots. Stripe i la majoria dels MoR paguen segons un calendari continu (sovint 2–7 dies després del càrrec, a vegades setmanalment), de manera que un pagament que arriba el dia 5 del mes conté vendes dels darrers dies del mes anterior. Si registreu els pagaments com a ingressos el dia que arriben al banc, estareu atribuint malament els ingressos al període equivocat cada mes.
• Diverses extensions, un sol compte de processador. Si gestioneu diverses extensions mitjançant el mateix compte de Stripe o Paddle —habitual entre desenvolupadors que publiquen un grapat d'eines petites en lloc d'un sol producte estrella— el pagament és una única quantitat global que les cobreix totes. Sense un etiquetatge per extensió (els camps de metadades de Stripe, o Productes/Preus separats per extensió), no podeu saber quina extensió ha generat realment els ingressos, cosa que fa impossible determinar quina val la pena mantenir.
• Comissions, reemborsaments i conversió de moneda ja descomptats abans que vegeu la xifra. L'import del pagament ja és net de les comissions de processament, de qualsevol reemborsament emès en aquell període i de la conversió de moneda si veneu internacionalment. Registrar el pagament com a ingrés brut sobreestima la vostra facturació i amaga el vostre marge real.

La solució és una conciliació a tres bandes, feta com a mínim mensualment:

1. Informe de vendes del processador — transaccions brutes, desglossades per producte/extensió si el vostre compte ho permet, abans de descomptar comissions i reemborsaments.
2. Informe de pagaments del processador — els imports nets que realment s'han transferit al vostre banc, amb les comissions i els reemborsaments desglossats com a línies separades.
3. Extracte bancari — els dipòsits que realment s'han fet efectius.

Feu coincidir els tres. L'informe de vendes us diu què heu guanyat (ingressos, reconeguts quan el client va pagar pel període de servei). L'informe de pagaments us indica l'impacte de les comissions i l'activitat de reemborsaments que cal registrar com a despeses i com a contra-ingressos. L'extracte bancari confirma que els diners realment han arribat. Quan dos qualssevol dels tres no quadren, aquesta és la vostra senyal que cal investigar alguna cosa: un pagament fallit, un contracàrrec disputat, o una comissió del processador que no esperàveu.

El risc específic de Chrome: retards de revisió i retirades​

Tota pila de pagaments té activitat de reemborsament ordinària. Les extensions de Chrome tenen un mode de fallada addicional que val la pena fer un seguiment com a línia pròpia: els retards de revisió i les retirades per incompliment de polítiques de la Chrome Web Store.

Quan l'equip de revisió de Google marca una extensió publicada per un incompliment de política, obteniu una retirada immediata (per a infraccions de moderades a greus) o un període d'avís d'aproximadament 7 a 30 dies per corregir-ne una de menor. En qualsevol dels dos casos, els usuaris perden l'accés a una extensió per la qual estan pagant activament, i això genera un pic previsible de sol·licituds de reemborsament, contracàrrecs i tiquets de suport —hi ha desenvolupadors que han reportat pèrdues de percentatges de dos dígits dels ingressos mensuals per subscripció exactament per aquest patró, a més dels reemborsaments directes.

Dos hàbits comptables fan que això sigui gestionable en lloc d'una sorpresa:

• Etiqueteu els reemborsaments i contracàrrecs per causa. Un reemborsament perquè a un client no li ha agradat l'extensió és un cost normal del negoci. Un reemborsament perquè la vostra extensió va estar retirada durant una setmana és un risc de negoci diferenciat i rastrejable. Separar-los (encara que només sigui amb un camp de memo o un subcompte) us permet veure, al llarg d'un any, quanta volatilitat d'ingressos prové del risc de plataforma en comparació amb l'ajust producte-mercat.
• Tracteu una revisió pendent o un avís de política obert com un esdeveniment digne de divulgar, de la mateixa manera que marcaríeu un risc de pèrdua d'un client clau. Si esteu fent números per decidir si pujar preus, contractar ajuda o demanar un préstec, una extensió que actualment té un avís de compliment de 30 dies no és "ingrés recurrent estable" —modelitzeu-la com a en risc fins que superi la revisió.

Reconeixeu els ingressos quan els guanyeu, no quan arriba el pagament​

Les extensions de subscripció i les de compra única necessiten un tractament diferent, i confondre'ls és l'error comptable més comú en aquest nínxol:

• Subscripcions mensuals o anuals: reconeixeu els ingressos de manera uniforme al llarg del període pel qual paga el client, no tots de cop quan es fa el càrrec. Un pla anual pagat per endavant crea un passiu d'ingressos diferits —heu cobrat, però encara no heu prestat onze dels dotze mesos de servei, així que només 1/12 és ingrés el mes de la venda i la resta va sortint del balanç mes a mes.
• Ofertes de per vida (lifetime deals) (un model de preus popular específicament per a extensions, ja que els usuaris desconfien de les subscripcions contínues per a una eina de navegador): aquestes segueixen representant una obligació de proporcionar actualitzacions i suport indefinidament, així que reconèixer el 100% de l'efectiu com a ingrés el primer dia sobreestima els vostres ingressos realment guanyats aquell mes. Un enfocament més defensable reconeix els ingressos de les ofertes de per vida al llarg d'un període de servei estimat raonable (moltes empreses fan servir 12–36 mesos com a referència) en lloc de tot de cop.
• Compres úniques sense obligació contínua: reconeixeu-les íntegrament quan es lliurin —aquest és el cas senzill.

L'MRR (ingressos recurrents mensuals) és una mètrica de creixement útil, però no és el mateix número que els ingressos reconeguts als vostres llibres. L'MRR us indica el ritme anualitzat de les subscripcions actives; el vostre llibre major hauria de reflectir allò que realment heu guanyat aquest període després dels diferiments.

Una estructura de llibre major que sobreviu a diverses extensions​

Si porteu els llibres en un sistema de partida doble en text pla, la solució al problema de "un pagament, diverses extensions" és un pla de comptes que separi els ingressos per producte des del primer dia, més comptes explícits per a les deduccions que un informe de pagaments ja descompta:

2026-07-05 * "Stripe payout - batch #4471"
  Assets:Bank:Checking                      842.17 USD
  Income:Extensions:FocusTimer             -510.00 USD
  Income:Extensions:TabArchiver            -390.00 USD
  Expenses:PaymentProcessing:StripeFees      41.83 USD
  Expenses:Refunds:FocusTimer                16.00 USD

Cada pagament esdevé una única transacció que concilia el dipòsit bancari amb els ingressos, comissions i reemborsaments per extensió com a apunts separats —en lloc d'una línia opaca de "dipòsit de Stripe" que no us diu res sobre quin producte és realment rendible. Com que el fitxer és text pla, podeu fer-hi grep o consultes per extensió, per mes o per causa del reemborsament, que és exactament la visibilitat que un informe de pagament en bloc no us dona.

Una llista de verificació mensual​

1. Descarregueu l'informe de vendes del processador del mes (brut, desglossat per producte si és possible).
2. Descarregueu l'informe de pagaments i separeu les comissions, els reemborsaments i els contracàrrecs en línies pròpies.
3. Confirmeu els dipòsits de pagament contra l'extracte bancari.
4. Registreu els ingressos de subscripcions i ofertes de per vida segons un calendari de reconeixement, no en el moment de cobrament.
5. Etiqueteu per separat qualsevol reemborsament vinculat a un retard de revisió o una retirada de la Chrome Web Store, diferenciant-lo de la baixa ordinària.
6. Si veneu internacionalment mitjançant un processador de pagaments directe (no un MoR), comproveu si les vostres vendes acumulades en algun país han superat un llindar de registre d'IVA/GST.

Mantingueu els llibres del vostre negoci d'extensions tan nets com el vostre codi​

No publicaríeu una extensió sense control de versions, i les vostres finances es mereixen la mateixa disciplina —especialment un cop els pagaments es reparteixen entre diversos productes i processadors. Beancount.io ofereix comptabilitat en text pla i amb control de versions que us permet etiquetar els ingressos per extensió, fer seguiment dels ingressos diferits i conciliar els pagaments amb el vostre extracte bancari amb la mateixa precisió que apliqueu al vostre codi. Comenceu gratis i descobriu per què els desenvolupadors gestionen els seus llibres de la mateixa manera que gestionen tot allò que construeixen.