Exemples de comptabilisation des revenus

Après avoir lu la page d’aperçu de Revenue Recognition et celle dédiée à la méthodologie de comptabilisation des revenus, mettez à profit les connaissances que vous avez acquises pour examiner les exemples ci-après. Sauf indication contraire, ces exemples prennent l’hypothèse d’une comptabilisation quotidienne des revenus. Bien que l’outil de Stripe comptabilise les revenus chaque milliseconde, le principe d’un incrément journalier simplifie les calculs.

Abonnement mensuel

Cet exemple se fonde sur les hypothèses suivantes :

• Le 15 janvier, à 0 h 00 UTC, un client souscrit un abonnement mensuel à 31 USD.
• L’abonnement fait l’objet d’une facture.
• La facture est finalisée et le client paie 31 USD.

Dans cet exemple, les périodes de facturation et de revenus s’étendent du 15 janvier 2019 au 14 février 2019. Les 31 USD sont comptabilisés sur 17 jours en janvier et 14 jours en février. Voici comment se présenterait le récapitulatif à la fin du mois de janvier :

Cela signifie que les revenus comptabilisés ont augmenté de 17 USD pour les jours de janvier, et que les revenus reportés, prévus pour être comptabilisés en février, ont augmenté de 14 USD.

Abonnement annuel

Cet exemple se fonde sur les hypothèses suivantes :

• Le 1er janvier, à 0 h 00 UTC, un client souscrit un abonnement annuel à 365 USD.
• L’abonnement génère une facture.
• La facture est finalisée et le client paie 365 USD.

Dans cet exemple, les périodes de facturation et de revenus s’étendent du 01/01/2019 au 31/12/2019. Les 365 USD sont comptabilisés quotidiennement tout au long de l’année. Voici comment se présenterait le récapitulatif à la fin du mois de mars :

Abonnement mensuel facturé à la consommation

Il existe quatre types d’aggregate_usage, qui correspondent à différentes façons de comptabiliser les revenus.

Somme

Cet exemple se fonde sur les hypothèses suivantes :

• Le 15 janvier, un client souscrit un abonnement mensuel facturé à la consommation à 1 USD par unité, et avec aggregate_usage=sum.
• Le 25 janvier, le client utilise 15 unités.
• Le 4 février, le client utilise 17 unités supplémentaires.
• Le 14 février, l’abonnement génère une facture de 32 USD.
• La facture est finalisée pour 32 USD, mais n’est pas encore payée.

Dans cet exemple, les périodes de facturation et de revenus s’étendent du 15 janvier 2019 au 14 février 2019. Bien que la facture ne soit générée que le 14 février, les 15 USD du 25 janvier doivent néanmoins être comptabilisés au moment où l’utilisation est intervenue. Voici comment se présenterait le récapitulatif à la fin du mois de janvier :

Voici comment se présenterait le récapitulatif à la fin du mois de février, sans que le paiement de la facture soit encore intervenu :

Max.

Cet exemple se fonde sur les hypothèses suivantes :

• Le 15 janvier, un client souscrit un abonnement mensuel facturé à la consommation à 1 USD par unité, et avec aggregate_usage=max.
• Le 25 janvier, le client utilise 17 unités.
• Le 4 février, le client utilise 15 unités supplémentaires.
• Le 14 février, l’abonnement génère une facture de 17 USD.

Dans cet exemple, les périodes de facturation et de revenus s’étendent du 15 janvier au 14 février 2019. Voici comment se présenterait le récapitulatif à la fin du mois de janvier :

Voici comment se présenterait le récapitulatif à la fin du mois de février, sans que le paiement de la facture soit encore intervenu :

Les 15 unités enregistrées le 4 février n’ont pas d’incidence sur la comptabilisation des revenus car il ne s’agit pas de la valeur maximale de l’enregistrement d’utilisation.

Dernière utilisation de la période

Cet exemple se fonde sur les hypothèses suivantes :

• Le 15 janvier, un client souscrit un abonnement mensuel facturé à la consommation au tarif de 1 USD par unité et avec le paramètre aggregate_usage=last_during_period.
• Le 25 janvier, le client utilise 17 unités.
• Le 27 janvier, le client utilise 10 unités.
• Le 4 février, le client utilise 15 unités supplémentaires.
• Le 14 février, l’abonnement génère une facture de 15 USD.

Dans cet exemple, les périodes de facturation et de revenus s’étendent du 15 janvier au 14 février 2019. Voici comment se présenterait le récapitulatif à la fin du mois de janvier :

Les 17 unités enregistrées le 25 janvier n’ont aucune incidence sur la comptabilisation des revenus, car il ne s’agit pas de la dernière utilisation enregistrée sur la période à la fin du mois de janvier.

Voici comment se présenterait le récapitulatif à la fin du mois de février, sans que le paiement de la facture soit encore intervenu :

Les 17 unités enregistrées le 25 janvier et les 10 unités enregistrées le 27 janvier n’ont aucune incidence sur la comptabilisation des revenus, car il ne s’agit pas des dernières utilisations enregistrées sur la période.

Dernière utilisation

Cet exemple se fonde sur les hypothèses suivantes :

• Le 15 janvier, un client souscrit un abonnement mensuel facturé à la consommation au tarif de 1 USD par unité et avec le paramètre aggregate_usage=last_ever.
• Le 25 janvier, le client utilise 17 unités.
• Le 27 janvier, le client utilise 10 unités.
• Le 4 février, le client utilise 15 unités supplémentaires.
• Le 8 février, le client utilise 18 unités supplémentaires.
• Le 14 février, l’abonnement génère une facture de 18 USD.
• Le 14 mars, l’abonnement génère une nouvelle facture de 18 USD.

Dans cet exemple, les périodes de facturation et de revenus s’étendent du 15 janvier au 14 février 2019. Voici comment se présenterait le récapitulatif à la fin du mois de janvier :

Les 10 unités enregistrées le 25 janvier n’ont aucune incidence sur la comptabilisation des revenus, car il ne s’agit pas de la dernière utilisation enregistrée à la fin du mois de janvier.

Voici comment se présenterait le récapitulatif à la fin du mois de février :

Pour la période du 14 février au 14 mars, étant donné qu’aucune utilisation n’a été enregistrée au cours de la période, nous comptabilisons 18 USD au moment de la facturation. Voici comment se présenterait le récapitulatif à la fin du mois de mars :

Passage à un abonnement supérieur

Cet exemple se fonde sur les hypothèses suivantes :

• Le 1er avril, à 0 h 00 UTC, un client souscrit un abonnement mensuel à 90 USD.
• L’abonnement génère une facture.
• La facture est finalisée le 1er avril et le client paie 90 USD.
• Le 21 avril à 0 h 00 UTC, le client passe à un abonnement mensuel à 120 USD.
  • Deux postes de facture non facturés sont créés pour représenter (1) -30 USD pour le temps inutilisé de l’abonnement précédent et (2) 40 USD pour la période restante du nouvel abonnement.
• La prochaine facture inclut les deux postes de facture non facturés et est finalisée le 1er mai à 0 h 00 UTC avec les 3 postes de facture suivants :
  • -30 USD pour le temps inutilisé de l’abonnement précédent avec la période de service s’étendant du 21 avril à 0 h 00 UTC au 1er mai à 0 h 00 UTC.
  • 40 USD pour le temps restant du nouvel abonnement avec la période de service s’étendant du 21 avril à 0 h 00 UTC au 1er mai à 0 h 00 UTC.
  • 120 USD pour le service en mai avec la période de service s’étendant du 1er mai à 0 h 00 UTC au 1er juin à 0 h 00 UTC.

Voici comment se présenterait le récapitulatif à la fin du mois de mai :

Passage à un abonnement inférieur

Cet exemple se fonde sur les hypothèses suivantes :

• Le 1er avril, à 0 h 00 UTC, un client souscrit un abonnement mensuel à 90 USD.
• L’abonnement génère une facture.
• La facture est finalisée le 1er avril et le client paie 90 USD.
• Le 21 avril à 0 h 00 UTC, le client passe à un abonnement mensuel inférieur qui coûte 30 USD.
  • Deux postes de facture non facturés sont créés pour représenter (1) -30 USD pour le temps inutilisé de l’abonnement précédent et (2) 10 USD pour la période restante du nouvel abonnement.
• La prochaine facture inclut les deux postes de facture non facturés et est finalisée le 1er mai à 0 h 00 UTC avec les 3 postes de facture suivants :
  • -30 USD pour le temps inutilisé de l’abonnement précédent avec la période de service s’étendant du 21 avril à 0 h 00 UTC au 1er mai à 0 h 00 UTC.
  • 10 USD pour le temps restant du nouvel abonnement avec la période de service s’étendant du 21 avril à 0 h 00 UTC au 1er mai à 0 h 00 UTC.
  • 30 USD pour le service en mai avec la période de service s’étendant du 1er mai à 0 h 00 UTC au 1er juin à 0 h 00 UTC.

Voici comment se présenterait le récapitulatif à la fin du mois de mai :

Solde créditeur du client

Cet exemple se fonde sur les hypothèses suivantes :

• Le 15 janvier, à 0 h 00 UTC, un client souscrit un abonnement mensuel à 31 USD.
• L’abonnement génère une facture.
• La facture est finalisée le 15 janvier, à 0 h 00 UTC.
• Le client dispose de -11 USD dans son solde créditeur. Stripe applique automatiquement -11 USD à la facture et ajuste le solde créditeur du client à 0 USD.
• Le 9 février, le client paie 20 USD.

Dans cet exemple, les périodes de facturation et de revenus s’étendent du 15/01/2019 au 14/02/2019. Les 31 USD sont comptabilisés sur 17 jours en janvier et 14 jours en février. Voici comment se présenterait le récapitulatif à la fin du mois de janvier :

Dans ce scénario, le client dispose d’un solde créditeur qui est utilisé pour payer la facture. Il est également possible qu’un montant négatif sur une facture crédite le solde créditeur du client, qui est ensuite utilisé pour payer la facture. Cela se produit souvent lorsqu’un client passe à un abonnement moins cher. Par exemple, prenons les hypothèses suivantes :

• Une facture de -31 USD avec un poste de facture est finalisée le 15 janvier à 0 h 00 UTC.
• La période de service du poste de facture de -31 USD s’étend du 15 janvier 0 h 00 UTC au 15 février 0 h 00 UTC.
• Stripe crédite automatiquement de 31 USD le solde créditeur du client et clôt la facture.

Le poste -31 USD enregistre une écriture de journal qui débite DeferredRevenue et crédite AccountsReceivable. Lorsque Stripe crédite le solde créditeur du client, une autre écriture est passée au débit de AccountsReceivable et au crédit de CustomerBalance. Voici comment se présenterait le récapitulatif à la fin du mois de janvier :

Notez que les revenus nets sont finalement de -31 USD.

Remboursement

Cet exemple se fonde sur les hypothèses suivantes :

• Le 1er janvier, à 0 h 00 UTC, un client souscrit un abonnement de trois mois à 90 USD.
• L’abonnement génère une facture.
• La facture est finalisée et le client paie 90 USD.
• Le 1er février, le client reçoit un remboursement intégral.

Lorsque vous effectuez un remboursement intégral :

• Le client reçoit une somme d’argent.
• Les revenus comptabilisés sont compensés par des contreparties de revenus dans le compte des remboursements.
• Les revenus reportés de l’abonnement qui n’ont pas été comptabilisés sont soldés.

Dans cet exemple, le client a bénéficié d’un mois de service, et 31 USD de revenus comptabilisés sont donc remboursés. Le remboursement diminue par ailleurs le solde de trésorerie de votre compte Stripe de 90 USD. Au moment du remboursement, il restait 59 USD de revenus reportés, qui sont donc également soldés. Voici comment se présenterait le récapitulatif à la fin du mois de mars :

Remboursement partiel

Cet exemple se fonde sur les hypothèses suivantes :

• Le 1er janvier, à 0 h 00 UTC, un client souscrit un abonnement de trois mois à 90 USD.
• L’abonnement génère une facture.
• La facture est finalisée et le client paie 90 USD.
• Le 1er février, le client reçoit un remboursement partiel de 9 USD.

Quand le remboursement partiel est effectué :

• Le client reçoit 9 USD.
• Les revenus comptabilisés sont proportionnellement compensés par des contreparties de revenus dans le compte des remboursements.
• Les revenus reportés de l’abonnement qui n’ont pas été comptabilisés sont également réduits proportionnellement.

Dans cet exemple, le client a bénéficié d’un mois de service, et 31 USD ont donc été comptabilisés. Il reste 59 USD de revenus reportés. Le remboursement partiel de 9 USD représente 10 % de 90 USD. Par conséquent, le compte des remboursements (part des contreparties de revenus) est augmenté de 3,10 USD (10 % de 31 USD), et les revenus reportés sont diminués de 5,90 USD (10 % de 59 USD). Voici comment se présenterait le récapitulatif à la fin du mois de mars :

Facture nulle

Cet exemple se fonde sur les hypothèses suivantes :

• Le 1er janvier, à 0 h 00 UTC, un client souscrit un abonnement de trois mois à 90 USD.
• L’abonnement génère une facture.
• La facture est finalisée, mais le client n’a pas encore payé.
• Le 1er février, vous annulez la facture.

Lorsque vous annulez la facture :

• Le compte des créances est apuré, car nous ne nous attendons pas à être payés.
• Les revenus comptabilisés sont compensés par des contreparties de revenus dans le compte des annulations.
• Les revenus reportés de l’abonnement qui n’ont pas été comptabilisés sont soldés.

Dans cet exemple, le client a bénéficié d’un mois de service, et 31 USD de revenus comptabilisés ont donc été annulés. Au moment où la facture a été annulée, il restait 59 USD de revenus reportés, qui sont donc également soldés. Voici à quoi ressemblerait le récapitulatif à la fin du mois de mars :

Facture irrécouvrable

Cet exemple se fonde sur les hypothèses suivantes :

• Le 1er janvier, à 0 h 00 UTC, un client souscrit un abonnement de trois mois à 90 USD.
• L’abonnement génère une facture.
• La facture est finalisée, mais le client n’a pas encore payé.
• Le 1er février, la facture est marquée comme non recouvrable.

Lorsque la facture est marquée comme irrécouvrable :

• Le compte des créances est apuré, car nous ne nous attendons pas à être payés.
• Les revenus comptabilisés sont compensés par des contreparties de revenus dans le compte des créances irrécouvrables.
• Les revenus reportés de l’abonnement qui n’ont pas été comptabilisés sont soldés.

Dans cet exemple, le client a bénéficié d’un mois de service, et 31 USD de revenus comptabilisés deviennent donc des créances irrécouvrables. Au moment où la facture a été marquée comme irrécouvrable, il restait 59 USD de revenus reportés, qui sont donc également soldés. Voici comment se présenterait le récapitulatif à la fin du mois de mars :

Une facture irrécouvrable peut quand même être payée. Lorsque la facture est payée, le compte de créances irrécouvrables est apuré en utilisant une partie du montant en liquidités reçu. Le montant restant va dans le compte des créances recouvrables. Si la facture est payée en avril, voici comment se présentera le récapitulatif :

Une facture non recouvrable peut quand même être annulée. Lorsque la facture est annulée, le compte de créances non recouvrables est apuré et son contenu est transféré dans le compte des annulations. Voici ce à quoi ressemblerait le récapitulatif avec une annulation de la facture en avril :

Factures non recouvrables avec application du solde créditeur d’un client

Cet exemple se fonde sur les hypothèses suivantes :

• Le 15 janvier, à 0 h 00 UTC, un client souscrit un abonnement mensuel à 31 USD.
• L’abonnement génère une facture.
• La facture est finalisée le 15 janvier, à 0 h 00 UTC.
• Le client dispose de -11 USD sur son solde créditeur. Stripe applique automatiquement -11 USD à la facture et ajuste le solde créditeur en conséquence.
• Le 15 février, la facture est marquée comme non recouvrable.

Dans cet exemple, les périodes de facturation et de revenus s’étendent du 15 janvier 2019 au 14 février de la même année. Stripe répartit la comptabilisation des 31 USD sur 17 jours en janvier et 14 en février.

Stripe compense automatiquement le compte des créances irrécouvrables avec les revenus comptabilisés si une facture est classée non recouvrable. Sur les 11 USD du solde créditeur du client, Stripe considère que 6 USD (11 x 17 / 31) sont des revenus comptabilisés et que 5 USD (11 x 14 / 31) sont des revenus reportés. Les revenus reportés payés sont considérés comme un gain et enregistrés dans le compte des créances recouvrables.

Voici à quoi ressemblerait le récapitulatif à la fin du mois de février :

Autre exemple : vous pouvez augmenter le montant dû de la facture d’un client s’il possède un solde impayé (c’est-à-dire qu’il vous doit de l’argent). Imaginons la situation suivante :

• Une facture de 31 USD avec un poste de facture est finalisée le 15 janvier à 0 h 00 UTC.
• La période de service du poste de facture de 31 USD s’étend du 15 janvier 0 h 00 UTC au 15 février 0 h 00 UTC.
• Le solde créditeur du client s’élève à 10 USD. Pour cette raison, Stripe ajoute ce montant à la facture et le solde impayé tombe à 0 USD.
  • AcountsReceivable est débité de 10 USD, qui sont ensuite crédités sur CustomerBalance.
• Le 15 février, Stripe marque la facture comme non recouvrable.

Sur une facture non recouvrable, la part du solde créditeur du client qui est à régler n’est pas collectée. En conséquence, elle est considérée comme une perte et est enregistrée comme un montant négatif dans le compte des créances recouvrables.

Voici à quoi ressemblerait le récapitulatif à la fin du mois de février :

Facture irrécouvrable et contestée ou remboursée

Une facture irrécouvrable peut être payée avant d’être ensuite contestée et/ou remboursée.

Cet exemple se fonde sur les hypothèses suivantes :

• Le 1er janvier, à 0 h 00 UTC, un client souscrit un abonnement de trois mois à 90 USD.
• L’abonnement génère une facture.
• La facture est finalisée, mais le client n’a pas encore payé.
• Le 1er février, la facture est marquée comme non recouvrable.
• Le 1er avril, la facture est payée.
• Le 1er mai, le paiement correspondant est contesté.

Comme illustré dans l’exemple « Facture irrécouvrable », lorsque la facture est marquée comme irrécouvrable, puis est payée ultérieurement :

• Le compte des créances irrécouvrables est apuré.
• Le reste est comptabilisé en tant que créances recouvrables.

Dans cet exemple, le client décide ultérieurement de contester le paiement. En cas de litige, le récapitulatif sera similaire à celui illustré ci-dessous :

Une facture marquée comme irrécouvrable, payée, puis remboursée fonctionne de la même manière, excepté que le compte de remboursement est utilisé au lieu du compte de litige.

Litige

En cas de litige, la comptabilisation des revenus fonctionne de la même manière que pour un remboursement, excepté que c’est le compte de litiges qui est dès lors utilisé. Cet exemple vous montre également ce qui se passe dans le cas d’un litige que vous remportez, en prenant pour base les hypothèses suivantes :

• Le 1er janvier, à 0 h 00 UTC, un client souscrit un abonnement de trois mois à 90 USD.
• L’abonnement génère une facture.
• La facture est finalisée et le client paie 90 USD.
• Le 1er février, le client conteste le paiement.
• Le 1er avril, vous remportez le litige, la banque ayant statué en votre faveur.

Lorsque le client initie un litige :

• Les liquidités sont restituées au client.
• Les revenus comptabilisés sont compensés par des contreparties de revenus dans le compte des litiges.
• Les revenus reportés de l’abonnement qui n’ont pas été comptabilisés sont soldés.

Lorsque vous remportez le litige :

• Les liquidités vous sont restituées.
• Les revenus comptabilisés et les revenus reportés ne sont pas modifiés.
• Les liquidités sont compensées par une augmentation du compte des créances.

Dans cet exemple, le client a bénéficié d’un mois de service, et 31 USD de revenus comptabilisés sont donc contestés. Le litige diminue également le solde de trésorerie de votre compte Stripe de 90 USD. Au moment du litige, il restait 59 USD de revenus reportés, qui sont donc également soldés. Plus tard, en avril, la banque statue en votre faveur, et les liquidités vous sont restituées.

Voici comment se présenterait le récapitulatif à la fin du mois d’avril :

Avoir après un paiement

Vous pouvez utiliser un remboursement, un crédit client ou un crédit en dehors de Stripe pour envoyer un avoir à un client après qu’il a effectué un paiement.

Par exemple, disons qu’un client démarre un abonnement pour une période de 3 mois le 1er janvier à 00:00:00 UTC, pour un montant de 90 USD. L’abonnement génère une facture et le client la règle immédiatement. Le 1er février, vous émettez un avoir de 45 USD divisé comme suit : remboursement de 15 USD ; crédit de 10 USD sur le solde du client ; crédit de 20 USD sur un solde client externe (crédit en dehors de Stripe). Votre récapitulatif pour le mois de mars ressemblerait à ceci :

Avoir sans postes

Cet exemple se fonde sur les hypothèses suivantes :

• Le 1er janvier, à 0 h 00 UTC, un client souscrit un abonnement de 6 mois à 181 USD.
• L’abonnement génère une facture.
• La facture est finalisée, mais le client n’a pas encore payé.
• Le 1er février, vous émettez un avoir de 90,50 USD.

Lorsque l’avoir est émis :

• Le montant de l’avoir est déduit du compte des créances.
• Le revenu comptabilisé est compensé proportionnellement par des contreparties de revenus dans le compte des avoirs.
• Les revenus reportés de l’abonnement qui n’ont pas été comptabilisés sont réduits proportionnellement au montant de l’avoir.

Voici à quoi ressemblerait le récapitulatif à la fin du mois de mars :

Lorsque l’avoir est annulé le 3 mai :

• Le compte des avoirs est annulé.
• Le montant des compte débiteurs est augmenté pour correspondre au montant dû originel de la facture.
• Le revenu réduit est comptabilisé en mai plutôt qu’en février, en mars ou en avril.
• Les revenus reportés réduits sont reversés en mai.

Voici à quoi ressemblerait le récapitulatif à la fin du mois de juin :

Veuillez noter qu’un avoir sans postes ne correspond pas à un poste de facture spécifique. Le montant de l’avoir est divisé proportionnellement entre les postes de la facture.

Avoir avec postes

Un avoir avec postes fonctionne de la même manière qu’un avoir sans postes, à ceci près qu’un poste d’avoir est utilisé pour réajuster les comptes de revenus et autres comptes pour un poste de facture correspondant.

Avoir avec postes négatifs

Les réajustements de comptes pour un avoir comportant des postes négatifs sont l’inverse de ceux pour un avoir comportant des postes positifs.

Découvrez comment créditer des postes de facture négatifs dans le Dashboard ou de façon programmatique avec l’API.

Actif externe

Lorsque vous marquez manuellement des factures comme étant payées en dehors de Stripe, le compte d’actifs externes est augmenté. Tous les autres comptes fonctionnent comme si la facture avait été payée, à l’exception du compte de trésorerie, qui n’est pas modifié. Vous pouvez importer des données de transactions tierces et consolider toutes vos sources de revenu dans vos rapports Stripe en utilisant la fonctionnalité Importer des données.

L’exemple ci-dessous concerne le compte d’actifs externes et se base sur les hypothèses suivantes :

• Le 1er janvier, à 0 h 00 UTC, un client souscrit un abonnement mensuel à 31 USD.
• L’abonnement génère une facture, qui est finalisée le jour même.
• La facture est marquée manuellement comme payée en dehors de Stripe le 5 février.

Exonération fiscale

Vos clients peuvent avoir un statut d’exonération fiscale de exempt ou reverse. Dans les deux cas, aucune taxe n’est appliquée à la facture.

Par exemple, disons qu’un client dont le statut d’exonération fiscale est reverse démarre un abonnement mensuel le 1er janvier à 00:00:00 UTC. Le montant de cet abonnement est de 31 USD par mois et son taux d’imposition TTC est de 10 %. Étant donné que le client est exonéré de taxe, le montant total dû est de 27,90 USD. L’abonnement génère une facture, cette facture est finalisée et le client la paie le même jour. Votre entrée de journal se présenterait comme suit :

Taux TTC sur les postes de factures

Un élément de facture peut inclure un taux d’imposition TTC. Lorsque vous ajoutez un élément de facture à une facture, cet élément peut utiliser le même exercice comptable ou un exercice différent de sa date de création.

Exercice comptable identique

Par exemple, disons qu’un client démarre un service pour une période d’un mois le 1er janvier à 00:00:00 UTC. Le montant total dû est de 34,10 USD et le taux d’imposition TTC est de 10 %. Vous ajoutez le poste de facturation à une facture le 1er janvier, cette facture est finalisée et le client la paie le même jour. Votre entrée de journal se présenterait comme suit :

Exercice comptable différent

Par exemple, disons qu’un client démarre un service pour une période de 3 mois le 1er janvier à 00:00:00 UTC. Le montant total dû est de 100,00 USD et le taux d’imposition TTC est de 10 %. Vous ajoutez le poste de facturation à une facture le 1er mars, cette facture est finalisée et le client la paie le même jour. Votre entrée de journal se présenterait comme suit :

Dette fiscale

Les factures et les postes de facture peuvent se voir attribuer des taux de taxe. Une fois que les taux de taxe sont affectés, les rapports Revenue Recognition calculent les taxes dues.

L’exemple donné ci-dessous utilise un taux hors taxes et se base sur les hypothèses suivantes :

• Le 1er janvier, à 0 h 00 UTC, un client souscrit un abonnement mensuel qui coûte 31 USD avec un taux hors taxes de 10 %. Le montant total à régler est de 34,10 USD.
• L’abonnement génère une facture.
• La facture est finalisée et payée le même jour.

L’exemple donné ci-dessous utilise un taux TTC et se base sur les hypothèses suivantes :

• Le 1er janvier, à 0 h 00 UTC, un client souscrit un abonnement mensuel qui coûte 31 USD avec un taux TTC de 10 %. Le montant total à régler est de 31 USD.
• L’abonnement génère une facture.
• La facture est finalisée et payée le même jour.

Multi-devises

Cet exemple se fonde sur les hypothèses suivantes :

• Le 1er janvier, à 0 h 00 UTC, une facture est finalisée et le client paie immédiatement 30 EUR.
• La devise de règlement de votre compte est l’USD.
• Le taux de change EUR/USD est de 1,20 au moment de la finalisation et du paiement.

Dans cet exemple, vous recevez 36 USD. Comme la facture est finalisée et payée immédiatement, son montant n’est pas affecté par les fluctuations des taux de change, et aucun gain ni aucune perte de change n’ont lieu.

Perte de change

Cet exemple se fonde sur les hypothèses suivantes :

• Le 1er janvier, à 0 h 00 UTC, une facture est finalisée pour 30 EUR.
• Le 1er février, à 0 h 00 UTC, le client paie la facture de 30 EUR.
• La devise de règlement de votre compte est l’USD.
• Le taux de change EUR/USD est de 1,20 au moment de la finalisation.
• Le taux de change EUR/USD est de 1,10 au moment du paiement.

Dans cet exemple, le taux de change a évolué entre la finalisation de la facture et le paiement, de sorte que vous recevez 33 USD, et non 36.

Perte de change en raison d’un remboursement ou d’un litige

Cet exemple se fonde sur les hypothèses suivantes :

• Le 1er janvier, à 0 h 00 UTC, une facture est finalisée pour 30 EUR.
• Le 1er février, à 0 h 00 UTC, le client paie la facture de 30 EUR.
• Le 1er mars, à 0 h 00 UTC, un remboursement de 30 EUR est effectué.
• La devise de règlement de votre compte est l’USD.
• Le taux de change EUR/USD est de 1,20 au moment de la finalisation.
• Le taux de change EUR/USD est de 1,20 au moment du paiement.
• Le taux de change EUR/USD est de 1,30 au moment du remboursement.

Dans cet exemple, le taux de change a évolué entre le paiement de la facture et le remboursement, de sorte que vous recevez 36 USD, mais remboursez ensuite 39 USD. Votre perte de change s’élève donc à 3 USD.

Veuillez noter qu’un litige fonctionne de la même manière qu’un remboursement, excepté que c’est le compte de litiges qui est utilisé en lieu et place du compte de remboursements.

Devises de règlement multiples

Cet exemple se fonde sur les hypothèses suivantes :

• Votre compte effectue les virements de fonds en USD par défaut, mais il prend également en charge l’EUR comme devise de règlement.
• Le 1er janvier, à 0 h 00 UTC, deux factures sont finalisées pour deux clients distincts : une de 30 EUR et l’autre de 400 NOK.
• Le taux de change NOK/USD est de 0,10 au moment de la finalisation et du paiement.
• Les deux factures sont payées immédiatement.

Dans cet exemple, vous recevez 40 USD de la transaction NOK et 30 EUR de la transaction EUR. Comme l’EUR est une devise de règlement prise en charge, aucun taux de change n’est appliqué.

Frais Bêta

Cet exemple se fonde sur les hypothèses suivantes :

• Le 1er janvier, à 0 h 00 UTC, un client souscrit un abonnement de trois mois à 90 USD.
• L’abonnement génère une facture.
• La facture est finalisée et le client paie 90 USD.
• Ce paiement entraîne des frais de traitement Stripe de 0,02 USD.

Si vous affichez le récapitulatif à la fin du mois de mars, vous verrez ceci :

Les frais de préavis sont comptabilisés au comptant.

Exclure des transactions

Une fois les transactions exclues, leur comportement diffère selon qu’elles ont été payées ou non. Si une transaction est payée en espèces, nous débitons le compte de liquidités et créditons le compte d’exclusion après l’exclusion. Si le montant est payé par CustomerBalance, nous débitons le solde du client et créditons le compte des réajustements du solde du client après l’exclusion. Nous ne générons pas d’écritures pour les transactions impayées. Leur comportement est le même que si la transaction n’avait jamais eu lieu.

Si vous excluez les transactions d’une période comptable clôturée, des corrections seront apportées aux transactions déjà payées. En savoir plus sur les corrections.

Exclure les transactions payées

Cet exemple se fonde sur les hypothèses suivantes :

• Le 5 janvier 2022, à 09 h 00 UTC, vous créez un paiement ponctuel de 10 USD à l’aide du Dashboard, des API Charges ou des API Payment Intents.
• Par défaut, Revenue Recognition reconnaît immédiatement les revenus de ce paiement ponctuel.
• Le 5 février 2022, vous excluez le paiement.
• La période comptable de janvier 2022 est clôturée ou ouverte.

Après avoir exclu le paiement :

• Les revenus passent à 0 USD, car le paiement n’en génère aucun.
• Le compte de liquidités reste à 10 USD, confirmant le paiement reçu.
• Un montant de 10 USD est ajouté au compte d’exclusion.

Voici les données récapitulatives que vous obtenez à la fin du mois de février :

Exclure les transactions impayées

Cet exemple se fonde sur les hypothèses suivantes :

• Le 1er janvier 2022, à 0 h 00 UTC, un client souscrit un abonnement d’un mois (du 1er janvier au 31 janvier) qui coûte 31 USD.
• L’abonnement génère une facture.
• La facture est finalisée, mais le client n’effectue pas de paiement.
• Le 1er février 2022, vous excluez le paiement.
• La période comptable de janvier 2022 est ouverte.

Si vous excluez une facture finalisée au cours d’une période comptable ouverte, il ne reste aucune trace de l’activité associée à la facture. Nous supprimons toutes les activités du compte, à l’exception du compte de liquidités et du solde du client qui n’est pas impliqué dans ce cas. Nous ne générons pas d’écritures comptables associées à la finalisation et à l’exclusion de la facture.