Everything you need to know about the Stripe “Bulk Usage-Based Metered Billing” app — from how metered billing works to advanced usage reporting scenarios. If you can’t find what you’re looking for, feel free to contact our support team and we’ll get back to you promptly.
There is no manual registration or login required. Simply install the app from the Stripe Marketplace and open it inside your Stripe Dashboard. Your account is created automatically using your Stripe account details — your Stripe Account ID, name, email, and company name are used to set everything up instantly. From the app, click “Visit WebApp” and you will be logged in automatically every time. You cannot access the WebApp directly from a browser without going through the Stripe Dashboard first.
Before creating metered subscriptions (Module 1), you need: (1) Your customers already created in Stripe (use the Stripe Bulk Customer Importer if needed). (2) A Stripe Meter created in your Stripe Dashboard under Billing → Meters. (3) A recurring Price with usage_type=metered and the meter attached. For Module 2 (usage events), you additionally need your customers to already have active metered subscriptions using the correct metered price. Without an active subscription, usage events are recorded but never invoiced.
Price ID — go to Stripe Dashboard → Products → click a product → scroll to the Prices section. The Price ID starts with price_. Make sure you select a price with usage_type = metered and a Stripe Meter attached. Meter Event Name — go to Stripe Dashboard → Billing → Meters → click a meter. The event_name field shows the exact string to use in your file — e.g. api_requests. The Meter_Event_Name in your file must match this exactly, including case and underscores.
At the end of the billing cycle — never at creation. Unlike fixed-price subscriptions, metered subscriptions never generate a charge when they are created. The billing cycle begins when the subscription is activated, usage events accumulate throughout the cycle, and Stripe generates the invoice only at cycle end. At that point, Stripe either automatically charges the customer’s saved payment method (charge_automatically) or emails an invoice for manual payment (send_invoice) depending on the Collection_Method you set. The only exception is if you set a Setup_Fee — that fee is charged immediately at subscription creation, before any usage is reported.
No — usage events never cause immediate charges. When you upload usage events via Module 2, this app creates Billing Meter Events in Stripe. These events are recorded against the customer’s meter and accumulate throughout the billing cycle. No invoice is generated and no charge occurs when usage is reported. At the end of the billing cycle, Stripe automatically totals all accumulated usage, calculates the amount based on the metered price, and either charges or invoices the customer — depending on their subscription’s collection method.
Yes — and this is the normal pattern for usage-based billing. You can upload usage events for the same customer and the same meter multiple times during a billing cycle. Stripe accumulates all events. For example, if your price is $0.01 per unit and you upload 500 units on the 5th and 300 units on the 20th, Stripe bills 800 × $0.01 = $8.00 at cycle end. You can run Module 2 daily, weekly, or any frequency that matches your internal usage data generation — Stripe handles the aggregation automatically.
Stripe will still record the usage event against the meter, but the usage will never be invoiced. Without an active subscription using a metered price connected to that meter, there is no billing relationship to generate an invoice from. Always ensure customers have an active metered subscription (created via Module 1 or directly in Stripe) before uploading usage events for them. The app validates the file format but cannot verify live subscription status during upload — check the WebApp after import to review any Stripe API errors returned.
Yes. The billing frequency is determined by the Price ID — if the price is set to monthly in Stripe, usage accumulates for one month and is billed monthly. If it’s annual, usage accumulates for a year and is billed annually. You can mix different billing cycles across rows in the same file. You can also report usage multiple times per cycle regardless of the cycle length — Stripe aggregates everything until the cycle ends.
No — and this is important to understand. Module 1 is only for customers who do not yet have an active metered subscription. If a customer already has an active metered subscription in Stripe, you do not need to create another one. Creating a duplicate subscription will result in the customer being billed twice. Use Module 2 to report usage for customers with existing subscriptions. Module 1 and Module 2 are independent workflows designed to be used at different stages of the customer lifecycle.
When a trial is set via the Trial_Days field, the subscription becomes active immediately but billing is deferred until the trial ends. Usage events CAN be recorded during the trial period and will accumulate on the meter — but they will not be billed until the trial ends and the first billing cycle completes. After the trial expires, the billing cycle begins and all accumulated usage is included in the first invoice. This lets you offer free usage during a trial while still tracking consumption accurately from day one.
Use Backdate_Start_Date when a customer started using your service before their subscription was formally created in Stripe. By backdating, Stripe captures all usage events reported since that past date and includes them in the first invoice. This is especially powerful in metered billing — you can report historical usage events for a customer and then create a backdated subscription to capture them all in the first billing cycle. The app automatically applies proration_behavior: none internally when backdating to prevent unexpected proration charges.
This is optional and depends on your requirements. Metered subscriptions never charge anything at creation — the first charge only happens at billing cycle end. For many businesses this creates a cash flow problem or makes new customers feel like nothing was activated. A Setup Fee charges a one-time amount immediately at subscription creation — before any usage is reported or billed. Use it for onboarding fees, platform access fees, account activation charges, or any cost you want to recover upfront. The currency is automatically detected from the Price ID. Different amounts can be set per customer row.
When you set a Payment_Method_ID, the app sets it as the default payment method at the subscription level. At the end of every billing cycle, Stripe automatically charges that specific payment method for the accumulated usage amount — no manual action needed for any subsequent billing cycle. The customer’s other saved payment methods in Stripe are not affected. If a payment fails, Stripe’s built-in dunning and retry logic handles it automatically.
Yes — each row specifies its own Meter_Event_Name, so you can mix different meters in a single file upload. For example, row 1 could report api_requests for customer A, row 2 could report tokens_used for customer B, and row 3 could report storage_gb for customer A. Each event is routed to the correct meter independently. This means you can report your entire customer base across all your usage metrics in one upload.
The Meter_Event_Name must match exactly the event_name configured on the Stripe Meter in your Dashboard — it is case-sensitive. The format allows only lowercase letters, digits, and underscores. No spaces, no uppercase, no hyphens, no special characters. Examples: api_requests, tokens_used, emails_sent, storage_gb. The app validates the format during file upload — but cannot verify whether the meter name exists in your Stripe account until the import runs. If the event_name does not match an existing meter, Stripe returns an error for that row which is logged in your WebApp.
Each Stripe API call in this app uses a unique idempotency key based on the row ID, customer ID, and meter event name. This means if you upload and run the same file again — whether by accident or because the app was interrupted and resumed — already-processed rows are never re-submitted to Stripe. The app tracks which rows have been successfully processed and skips them on retry. Idempotency protection is applied at both the app level (row tracking) and the Stripe API level (idempotency keys), providing two layers of protection against duplicate usage events.
The maximum value accepted is 2,147,483,647 (the maximum value of a 32-bit integer). Practically, this is more than enough for any usage quantity per single event. If your actual usage for a customer in a period exceeds this, split it across multiple rows in the same file. The Usage_Quantity must be a positive whole number — decimals (e.g. 1.5) and zero are not accepted. Stripe meters count whole units only. If your usage data is fractional, round up before uploading.
Failed rows are logged in the WebApp with the exact error message returned by Stripe — so you know precisely what went wrong for each row. The import continues processing all remaining rows — one failure does not stop the entire batch. You can review all failed records in the WebApp, fix the underlying issue (e.g. incorrect meter name, expired payment method, missing subscription), and re-process just the failed rows without re-uploading or re-validating the entire file.
The app is designed to handle interruptions safely. When you re-open the Stripe app after a disconnection, you do not need to re-upload your file. Simply click the relevant fetch button in the Stripe app to reload your existing file data, and then start the import again. The app automatically resumes from where it stopped — rows that were already successfully processed are skipped. Idempotency keys ensure that nothing is created or reported twice, even if the same row is encountered again during resumption.
There is no hard technical limit on file size — the app processes rows in batches with real-time progress tracking, so large imports of hundreds or thousands of rows are handled reliably without timeouts or browser memory issues.
Coupons work automatically on every usage invoice generated at the end of each billing cycle. The discount behaviour depends on the coupon’s duration setting configured in your Stripe Dashboard: once — applies to the first usage invoice only, then removed automatically. repeating — applies for a set number of billing cycles, then removed. forever — applies to every usage invoice for the lifetime of the subscription. Your app passes the coupon ID — Stripe handles the duration and expiry automatically. No re-application is needed each cycle.
Yes — full tax support is included in Module 1. You can enable Stripe Tax automatic calculation per row (requires Stripe Tax to be configured in your Dashboard first). Alternatively, apply manual Tax Rate IDs (txr_) for fixed rates — both cannot be used together and validation catches this. For B2B invoicing compliance, you can display your business tax registration number (Account_Tax_Ids) and your customer’s own VAT/GST/ABN/EIN (Customer_Tax_IDs) directly on usage invoice PDFs — supporting compliance across any country.
Invoice Memo — free-text note shown on every usage invoice PDF and email your customer receives each billing cycle. Good for usage summaries, billing period references, or thank-you messages.
Custom Fields — structured key:value pairs shown in a table on every usage invoice PDF. Visible to customers. Use for PO numbers, project codes, contract references. Maximum 4 fields per invoice.
Metadata — internal key:value data attached to the subscription in Stripe. Never visible to customers. Only visible to you in the Stripe Dashboard and API. Use for CRM IDs, sales rep names, account codes, or any internal reference. Up to 50 keys.
Yes — every row in your file is completely independent. One customer can have a 14-day trial with a $99 setup fee and charge_automatically, while the next can have send_invoice with 30 days to pay and a 20% discount coupon. Different tax rates, different billing cycle anchors, different cancellation rules, different metadata — all fully per-customer, all from a single file upload. There is no requirement for any field to be consistent across rows.
You can reach our support team directly from the Stripe app dashboard and WebApp. You can also visit our Contact Support page or email us at support@asrrcrm.com. We aim to respond to all support requests within 48 hours. For faster resolution, please include your Stripe Account ID, a description of the issue, and the row number or customer ID if the issue is related to a specific record.
We take bug reports seriously and fix issues as quickly as possible. Visit our Bug Report page or email us at support@asrrcrm.com. Please include as much detail as possible — what you were doing, what you expected, what actually happened, and any error messages. Screenshots or a copy of your file (with sensitive data removed) are very helpful.
Absolutely — we love hearing from our users and feature suggestions directly shape our roadmap. Visit our Contact Support page or email us at support@asrrcrm.com with your suggestion. Describe what you would like to see and how it would help your workflow. Popular and frequently requested features are prioritised for upcoming releases. Every suggestion is read and considered by our team.
We would love to hear about your experience. Submit your review on our Submit a Review page or email us at support@asrrcrm.com. Your honest feedback helps other businesses discover and trust the app. If something did not go as expected, please reach out to our support team first — we would love the opportunity to make it right before you leave your feedback.
Stripe Bulk Usage-Based Metered Billing app lets you create metered subscriptions and report customer usage events in bulk — directly from your Stripe Dashboard using CSV, Excel and Google Sheets. No APIs. No scripts. No manual work.
