The Finance Report provides monthly totals of your Total Billed, Payments, and Expected Payments. The report also breaks down Total Billed into Sales, Discounts, Taxes, and Credits.
Sales are listed in the month the invoice is issued, whether or not payment has been received. Payments are also matched up with the month the invoice is issued, not the month they are received.
This way, you can measure your monthly performance in terms of total sales and track how much you have received and how much you are still waiting to receive.
Total Billed = Sales - Discounts + Taxes - Credits/Voids
If you do not collect Taxes, your Total Billed will be the same as your Revenue.
Sales are split into the below categories for better granularity:
- Recurring Plans: Revenue from subscriptions.
- One Time: One-time revenue charges.
- On/Off: Revenue from on/off components.
- Quantity-Based: Revenue from quantity-based components.
- Metered: Revenue from metered usage components.
- Prepaid Usage: Revenue from prepaid usage components.
- Event-Based: Revenue from event-based components.
- Setup Fees: Revenue from setup/initial fees.
- Trial Fees: Revenue from paid trials.
These are discounts or deductions applied to sales according to Chargify coupon/discount logic.
Discounts are further broken down into the following categories:
- Single-Use Coupons: Discounts from coupons that are only applied once.
- Multi-Use Coupons: Discounts from coupons that are applied to several billings but eventually fall off automatically.
- Recurring Coupons: Discounts from coupons that are applied at every billing (until they are manually removed).
- Other Coupons: Discounts from coupons whose lifetime/limits cannot be determined.
- Referrals: Discounts from refer-a-friend discounts.
Credits are divided into the following categories:
- Service Credits: Reductions to revenue from service credits.
- Proration: Reductions to revenue from prorations.
- Refund Credits: Reductions to revenue from refunds which were credited to the invoices.
- Voids: Reductions to revenue from part and fully voided invoices.
- Other: Reductions to revenue from other credits (e.g. credits which were granted as a result of backporting).
Payments are the amounts you have received against the Total Billed. These includes actual payments (from credit cards, checks, ACH, etc.) as well as deferred payments from Prepayments.
- Automated Payments: Payments received from automatic billing by Chargify, which is usually either from credit cards or ACH
- Check/Invoice Payments: Payments recorded manually in Chargify, such as check payments for invoices
- Amortized Prepayments: The amount applied to this period’s billings from Prepayments (i.e. a large up front check payment that is amortized and split among each period’s billings)
We calculate Total Collections which is your gross payments (before Refunds), and we calculate Net Payments by subtracting Refunds.
The report also lists Expected Payments which accounts for payments not yet received but that are still expected to arrive. These fall into three categories:
- In Dunning: The amount under active Dunning managed by Chargify. Moves to Uncollected if Dunning ends without capturing payment.
- In Collection: The amount pertaining to subscriptions that have failed Dunning but have open invoices.
- Unpaid Invoices: The amount due on open invoices. (i.e. non-automated billing collection methods).
From your Total Billed, Payments, and Expected Payments, we derive the Uncollected amount which is calculated as your Total Billed minus your Payments and Expected Payments. In other words, this is the amount that you billed but have not received nor expect to receive via Dunning or open invoice.
The original release of the Finance Report predates Relationship Invoicing. Because of this, some elements of the report look different for merchants that have not migrated.
- Sales are broken down into Recurring Plans, One Time, Add Ons, Usage, Setup Fees, Trial Fees, and Other.
- Credits are broken down into Proration and Balance Adjustments.
- Refunds are factored into Net Revenue
- Expected Payments breaks down into In Dunning and Uncollected
The values displayed in this report follow a financial-style formatting:
- Only the subtotal and total rows include the currency symbol:
- A regular data row displays
- A subtotal or total rows displays
- A regular data row displays
- Negative amounts are wrapped in parentheses:
-$10.00would be shown as
The Finance Report for Relationship Invoicing supports multicurrency. You can see your Finance Report segmented by one currency at a time.
You can export the data displayed in your Finance Report as a CSV by clicking on the “Summary” option in the Export menu. A complete listing of the data contained in this CSV can be found in our export documentation..
Similar to other exports, the CSV file will appear shortly in your list of Downloads.
You can also export a more detailed Finance Report CSV by month. Simply click on the Export button and then choose the month you wish to export:
This CSV follows a format that is slightly different than what is shown in the web-based Finance Report. It contains all of the data needed to recreate the web-based report, plus extra data that allows you even more insight. When imported into a spreadsheet application (such as Google Sheets), it will look like this:
For a complete listing of the data contained in this CSV, please view the Finance Report section here in our Exports documentation.
You can download exports that date back to the date your account was created within the system. However, the UI version of the report is limited to the last 12 months.
The CSV contains all of the data you need to see your revenue in the way that works best for you. This means that some data is repeated from row-to-row, so you may need to use filters or sorting in some cases to avoid double-counting.
The columns that have repeated data and context-sensitive meaning are the following (note: a full list of columns and their descriptions follows in the next section):
For lines in the “Sales” category, this field gives the amount of discount that was applied to just that line.
For lines in the “Discounts” category, this field gives the total discount attributed to a particular coupon that may have been spread across multiple sales lines.
This way, you can filter out Discount lines to see just how much each of your Sales lines was discounted, or you can include Discount lines to see how much discount is attributed to each coupon.
For lines in the “Sales” category, this field gives the amount of tax that was applied to just that line.
For lines in the “Taxes” category, this field gives the total tax attributed to a particular tax configuration that may have been applied across multiple sales lines.
This way, you can filter out Tax lines to see just how much each of your Sales lines was taxed, or you can include Tax lines to see how much tax was charged by each tax “rule”.
For lines in the “Sales” category, this field gives the amount of credit (i.e. non-cash adjustment that reduced the amount billed, such as a service credit) applied to just that line.
For lines in the “Credits” category, this field gives the total credit amount from a particular Adjustment transaction that may have been spread across several Sales lines.
You may filter out Credit lines to see just how your individual sales were affected by credits, or you can include Credit lines to see why (via the memo) credits were being applied in the first place.
For lines in the “Sales” category, this field gives the amount that has been paid on that particular line. For example, an amount between 0% and 100% of
billed_amount indicates a partial payment for the line.
For lines in the “Payments” category, this field gives the total payment amount from a particular Payment transaction that may have been spread across several Sales lines.
You may filter out Payment lines to see just how your individual sales have been paid, or you can include Payment lines to see which payments have been received.
The following spreadsheet shows some of these concepts in action:
In the blue box, you can see that a $29.90 discount (#1) was applied to the Pro Plan Recurring Plan line, and $3.26 discount (#2) was applied to the Widgets Add On line. In all, this amounted to a discount of $33.16 (#3) on this sale, which came from the coupon with ID
40276 and the name “10% off the lifetime of your subscription”.
In the green box, you can see that the total billed amount of $269.10 has been paid (#4) on the Pro Plan Recurring Plan line. Also, the total billed of $29.34 has been paid (#5) on the Widgets Add On. This was captured in a single payment of $298.44 (#6) with transaction ID
You can download our example CSV file to take a look!
Values in rows with Sales category e.g.
payment_amount are calculated as fractional parts of these values for the whole Invoice and then rounded. This action may lead to discrepancy when we sum all values of the sales and then compare them to the Tax, Billed or Payment amount for the whole Invoice, because the rounded sum of all elements is not always equal to the sum of rounded elements.
The following spreadsheet shows an example:
In the red box we have two sales $2.99 and $4.99 (#1). The tax for this invoice is equal to 8.5%, therefore in the green box we have approximated tax (#2) for both sale items: $4.99 * 8.5% = $0,42415 ~= $0.42 and $2.99 * 8.5% = $0,25415 ~= $0.25. But for the whole invoice the tax is calculated (#3) as follows: ($4.99 + $2.99) * 8.5% = $0,6783 ~= $0.68. As we can see: $0.42 + $0.25 != $0.68, so in order to keep the correct calculations the
tax_amount from the whole invoice (#3) should be used.
Billed amount for each sales is calculated as follows
billed_amount = sale_amount - discount_amount + tax_amount -credit_amount therefore the discrepancy from the (#2)
tax_amount column for sales is propagated to the
billed_amount column (#4). In order to calculate
billed_amount for whole invoice the
tax_amount from the whole invoice (#3) should be used.
Payment amount for sale item is calculated as follows: paid fraction of invoice *
billed_amount. When the whole invoice is paid then the
billed_amount is equal to
payment_amount. As you see in the (#5) the payment amount for the sale item is approximated as well and the total amount of
payment_amount for the invoice will be different by $0.01 (#6).
Products that have recurring intervals of more than 1 month (i.e. annual products) will display all of their revenue in the month the sale hits instead of being spread out over several months. Spreading out the revenue into subsequent months is usually referred to as “Revenue Recognition” - we have a separate report built for this information, our Revenue Recognition suite.
If you’d like to use the Finance Report specifically for revenue recognition, there are a couple of workarounds:
If a subscription renews monthly, you can apply a large manual payment that covers several months. This is referred to as a “prepayment”, and displays in the Finance Report according to monthly revenue recognition rules: each month, the subscription bills for a single month and consumes a month’s worth of the prepayment. The revenue shown in the Finance Report will be the amount for one month.
This works most easily when your customer pays you via check. You can achieve a monthly subscription with a Prepayment by creating a subscription with Invoice billing and no credit card on file. Then, you’d enter the prepayment check as a manual payment.
In the CSV export, there is a column called “Period” which gives the recurring period of the line item. You can use this to track revenue recognition yourself by doing the math to back out the unrecognized portion and then recording and applying the “carryforward” amounts yourself.
For example, say you see a $1200 sale in January with a “12m” (12 month) recurring period. You know this equates to $100/mo, so you could subtract out the unrecognized portion of $1100 (for the remaining 11 months) from January and carry that forward as $100/mo for February through December.
If you experience a lack of credit notes for sales items from fully voided invoices, then you can use new functionality which ensure that offsetting credit will be applied to all historical and new voided invoices. You can enable this behavior via the invoice settings page. See the documentation for more details.