Proposed fixed-scope study
What should this invoice have charged?
A billing dry run can agree with the final invoice and still repeat the same missing price change. For one narrowly defined recurring-subscription scenario, we specify the expected invoice from approved catalog versions and dates, compare it with the dry run, and leave behind a release test.
This is billing accuracy work, and the failure it looks for is revenue leakage: billing less than was owed. We publish no industry percentage for it, because we have not measured one and the ranges in circulation do not name their method. The answerable question is narrower: if a price change failed to reach an invoice tonight, what in your pipeline would tell you? This study is $2,500 and covers one named scenario in your catalog.
This is an offer to conduct a study, not a deployed Nobulex billing product. No customer has purchased or run this study yet. The price is our proposed fee, not revenue received, and it is not a prediction about what a study here would find.
See a synthetic sample of the result →
Two-minute buyer-fit question: For a price change affecting existing subscriptions, what independent artifact tells your release team the amount and period the next invoice should contain? If your tests already cover it, that answer is useful too. Reply by email; no call or private data is needed.
Why this question
In Kill Bill issue #2291, the reporter describes a production-client case where a catalog price change did not reach the invoice, and says the dry run repeated the wrong amount. We reproduced two related paths locally on released Kill Bill 0.24.19 and opened separate fixes: PR #2320 and PR #2321. Those results are from test invoices, not a Nobulex customer or a production deployment. Read the evidence and limits.
What you provide
- One synthetic or sanitized recurring-subscription scenario, with approved catalog price versions and their effective dates.
- The intended billing period, billing-cycle day, and the approved rule for when each price takes effect.
- A Kill Bill dry-run response or a test environment where your team can run one. No production write access is needed.
- One billing owner who can confirm which price and period should control.
Do not send payment credentials, customer identities, full production invoices, API keys, or unrelated billing data. We can start with invented account identifiers and amounts.
What you receive
- A written expected-invoice calculation derived from the approved catalog and dates, independently of the dry-run amount.
- A line-by-line comparison: expected amount and period, dry-run amount and period, and any discrepancy or unresolved assumption.
- A runnable regression fixture for the agreed scenario, or an explicit explanation if the available inputs are insufficient to make one.
- A short result: confirmed mismatch, matching calculation, or indeterminate. A matching result is reported as such, not dressed up as a catch.
Boundaries
This first study covers one flat recurring price-change path in Kill Bill. Usage rating, taxes, discounts, credits, currency conversion, and legal interpretation are outside scope. We will not issue, alter, or block a real invoice. This is a release check for a named scenario, not a second general-purpose billing engine or a guarantee that every invoice is correct.
If the existing release tests already independently establish the expected amount, the study may find no additional control gap. That result is useful and will be stated plainly.
Commercial terms
| Fee | $2,500 proposed fixed fee for one agreed scenario and seven-day analysis. |
|---|---|
| Start | Scope and required inputs are agreed before payment or work begins. |
| Access | Read-only artifacts or a customer-run dry run. No production write access or payment credentials. |
| Publication | Private by default. No customer name, data, or result is published without written approval. |
Ask about the study
Send the billing system version, the kind of catalog change you want checked, and whether a synthetic example can represent it. No confidential data is needed for the first email.
Read the research →
