Choose the model by operating fit, not packaging preference: use transaction-led when demand is volatile, subscription-led when value is stable, and hybrid when you need both recurring predictability and usage-linked recovery. Validate with cohort cost behavior and procurement constraints, then test sample invoices across quiet, normal, and surge months. If Finance, Product, and Sales cannot explain every billed component consistently, hold launch until the charge logic is auditable and forecastable.
Step 1. Treat pricing as a revenue-model decision, not a packaging exercise. If you are choosing between transaction fees, subscription, and hybrid models, ask three questions: How does revenue behave against usage? How buyable is the model? Can Finance reconcile what Product and Sales sell?
Each model can fail in a different place. A transaction-fee model follows usage, but revenue is less predictable. A subscription model gives buyers a clearer budget number, but a flat fee can become harder to sustain if usage or service intensity rises faster than expected. The tradeoff is straightforward: pricing that is too rigid can limit growth, while pricing that is too loose can make revenue unpredictable.
Step 2. Choose with three filters, not one. The strongest choice usually sits at the intersection of unit economics, procurement reality, and execution risk.
Use these rules early:
Step 3. Understand why hybrid gets attention, and why it still fails. Hybrid pricing combines structures, usually a fixed recurring charge plus a variable usage-linked charge. The appeal is simple. You keep a stable recurring base while bills can still scale with usage. Practical overviews from Metronome and Stripe both frame hybrid pricing that way.
Adoption does not remove execution risk. Longer commitments can raise Total Contract Value (TCV), which can increase resistance, drive discount requests, and slow decisions. Variable components can also create invoice shock during usage spikes. One published hybrid example uses an included allowance, such as 1,000 API calls, with an upgrade trigger after the limit.
Step 4. Use this article to leave with a defensible operating choice. By the end, you should be able to:
If your model is hard to explain on an invoice, hard to forecast in a deal, or hard to reconcile at month-end, treat that as a pricing design problem, not a billing detail. That choice starts with evidence, not packaging language.
Related: Choosing Between Subscription and Transaction Fees for Your Revenue Model.
Do not design packaging first. Build a small evidence pack and assign owners up front. Pricing usually breaks where cost behavior, compliance gates, and invoice mechanics do not line up.
Start with three internal cuts: who owns fee-setting and collection, which transaction costs apply by payment rail, and which billing events define charges. The objective is simple: confirm how costs behave as usage grows.
| Fee input | Listed rate | Note |
|---|---|---|
| Domestic cards | 2.9% + 30¢ | Stripe lists this for domestic cards |
| Manually entered cards | +0.5% | Additional fee for manually entered cards |
| International cards | +1.5% | Additional fee for international cards |
| Currency conversion | +1% | Additional fee for currency conversion |
| ACH Direct Debit | 0.8% with a $5.00 cap | Stripe lists this for ACH Direct Debit |
Use fee components that match real payment mix, not blended averages. Stripe Connect pricing lists 2.9% + 30¢ for domestic cards, plus 0.5% for manually entered cards, 1.5% for international cards, and 1% for currency conversion. Stripe's managed payments pricing note also points to product-specific variations. ACH Direct Debit is 0.8% with a $5.00 cap. Treat listed rates as current inputs, not permanent constants, because country-specific pricing pages can supersede baseline fees.
Bring policy owners in early so pricing does not assume flows your controls cannot support. This matters most when the platform owns pricing decisions and fee collection.
On Stripe Connect, if you handle pricing, you are responsible for Stripe processing fees while collecting fees from users. Connect also defines auditable billing checkpoints: an account is active in months when payouts are sent, and a payout occurs each time funds are sent to a user's bank account or debit card. Validate any pricing assumption against those event definitions before a rate card goes live.
Confirm tax-handling assumptions for your priority markets before finalizing the model. The goal is not full tax analysis. It is to make sure the model can survive invoicing and reporting.
Validate fee-base assumptions carefully. Stripe states Managed Payments charges 3.5% per successful transaction on top of standard processing fees, and the fee calculation can include indirect taxes such as VAT or sales tax.
Assign clear ownership for billing and reconciliation. Have those owners confirm each planned charge against the billing events that trigger it so charge logic stays auditable, especially for monthly active account and payout-based charges.
Define each model in billing terms first: what triggers the charge, how it appears on an invoice, and how you will verify it internally.
For transaction-linked pricing, tie charges to a measurable event count. Because this is the variable side of the model, you need exact counting rules rather than broad "activity" language.
Set one clear checkpoint: document the trigger, exclusions, and billing timing. If different teams would count the same period differently, the metric is not ready.
Subscription pricing is a recurring fee, typically monthly or annually, for access. It is often used to create a more predictable revenue stream. Your operator check is entitlement clarity: state in one sentence what the customer gets each billing cycle.
Hybrid pricing can combine recurring charges with variable usage charges or negotiated commercial terms. Stripe treats hybrid pricing as a common model category, and Stripe Billing is positioned to support recurring billing, usage-based billing, and sales-negotiated contracts in one system. Make the structure explicit: state what is included by default and what is billed separately.
Keep the pricing metric and billing mechanic separate. The metric defines what you charge for. The billing mechanic defines how that charge becomes contract and invoice output.
Before you finalize the model, run Stripe's checkpoint directly: "Does the math hold up?" Validate it with a sample invoice and confirm the commercial logic is coherent end to end. Once those definitions are set, the next job is mapping them to how costs actually show up.
If you want a deeper dive, read Usage-Based Pricing for Payment Platforms: Per-Transaction vs. Subscription.
If cost to serve changes with usage and billing behavior, a flat-price assumption can eventually break. Map each cost driver to the operating event that creates it, then decide where subscription coverage is safe and where usage-linked recovery is required.
This is the handoff from billing design to unit economics. What you can bill is not always what you can safely absorb.
Start with drivers you can observe directly: usage intensity, entitlement state, invoice outcomes, and overage behavior. Do not treat them as one blended marginal cost, because they do not move in lockstep.
Use a simple cohort view with usage level, invoice output, and billing state. If you cannot point to the event trail creating an invoice outcome, do not hide it inside a flat fee.
Do not assume a flat marginal pattern across the product. Check where the behavior is created across metering, entitlements, and billing.
| Cost driver | Module or operating path to inspect | Revenue mechanic implication |
|---|---|---|
| Heavy usage | Metered usage events | Pure subscriptions can under-monetize heavy usage, so usage-linked recovery may be needed |
| Revenue predictability needs | Subscription plan structure | Pure usage can reduce predictability, so keep a subscription baseline where needed |
| Billing control state | Real-time checks of entitlements, usage, and billing | Approve subscription-heavy offers only if these states can be evaluated in real time |
| Invoice accuracy risk | Metering-to-billing handoff | Keep metering and billing connected enough to produce accurate invoices |
| Overage exposure | Credits and overage flows | Flexibility can add collections risk when customers exceed credits and pay later |
Price cohorts by operating reality, not by one default package.
Use subscription-heavy plans for low-variance cohorts and usage-linked recovery for high-variance cohorts. Pure subscriptions can under-monetize heavy usage, while pure usage can reduce revenue predictability.
This is the tradeoff Finance, Product, and Growth usually end up debating. A hybrid structure can bridge it, but only if metering and billing stay connected enough to produce accurate invoices. Before you approve a subscription-heavy offer, confirm you can evaluate entitlements, usage, and billing state in real time.
If margin breaks under high usage, do not launch pure subscription until overage protections or fixed-allowance upgrade paths exist. Protection can be usage charges or fixed allowances with upgrade pressure.
A practical pattern is a base plan with a defined allowance, then billed overage or an upgrade beyond that allowance. Keep one risk in view. Overage flexibility can create collections risk when customers exceed credits and pay later, so invoice logic needs to be ready before scale.
Need the full breakdown? Read Subscription Benchmark Report for Platform Operators: Churn Trials Payment Declines and LTV.
Match pricing mechanics to how costs move, how buyers buy, and how much billing complexity your team can operate. Treat transaction fee, subscription, and hybrid as points on a subscription-to-usage spectrum, then choose the model whose tradeoffs you can explain and run consistently.
| Model | Revenue predictability | Margin protection | Buyer predictability | Implementation complexity | Reconciliation burden |
|---|---|---|---|---|---|
| Transaction fee | Usage-linked; predictability depends on activity volatility | Depends on how closely price tracks activity-driven costs | Depends on how much usage can swing and how clearly bills are explained | Depends on event definitions, exception rules, and billing operations | Depends on how clearly variable charges and adjustments are represented |
| Subscription | Recurring structure (for example, $X per month, per user) supports planning clarity | Depends on whether fixed pricing matches real cost drivers over time | Often easier to forecast when pricing terms are clear | Depends on packaging, entitlements, and exception handling | Depends on invoice simplicity and how exceptions are managed |
| Hybrid | Positioned as a middle ground that blends subscription stability with metered flexibility | Depends on how base fees and usage charges map to cost drivers | Can support forecastable spend when pricing terms are explicit | Depends on clear design of both recurring and metered logic | Depends on clear reconciliation of fixed and variable components |
Use a quick invoice-explainability test before you commit. If Finance, Support, and Sales cannot explain low-usage and high-usage invoices without deep investigation, treat that as operational risk, especially where ongoing or hidden charges could be missed.
PLG and SLG fit is usually where the choice becomes clearer. Hybrid often works as a middle ground because it combines subscription stability with metered flexibility, and it can work in both self-serve PLG and enterprise-oriented SLG when spend remains forecastable.
| Scenario | Primary fit signal | Model implication |
|---|---|---|
| PLG self-serve | Self-serve adoption and changing usage patterns | Evaluate where you should sit on the subscription-to-usage spectrum; hybrid can be a workable option |
| SLG enterprise | Need for clear, forecastable spend | Evaluate subscription-oriented and hybrid structures that keep spend explainable |
| Mixed motions | Different buyer needs across segments | Use the spectrum framing to tune the fixed/usage mix rather than forcing one extreme |
Use a model-selection checklist before rollout:
If you need a default stance, anchor the decision on forecastability, invoice explainability, and your operating ability. Use the subscription-to-usage spectrum to choose the simplest model you can run consistently while keeping spend understandable for buyers.
Related: Hybrid Billing Models: How to Combine Subscriptions with Usage-Based and One-Time Charges.
Start with sales motion and usage predictability, then pressure-test unit economics before rollout. Use this as a starting heuristic: transaction-led or light hybrid pricing when usage is still hard to forecast, subscription-led pricing when recurring value is stable, and hybrid pricing when you need both a predictable base and usage-linked recovery.
A practical grid for the first decision:
| Motion signal | What usually matters most | Starting bias | Validation question |
|---|---|---|---|
| PLG or self-serve onboarding | Fast understanding and low commitment | Transaction-led or light hybrid | Can a new customer estimate likely spend from the pricing page and product usage view? |
| Mixed motion with growing account variance | Spend explainability and expansion control | Hybrid | Can your team explain base and usage charges clearly from contract terms and usage data? |
| SLG with procurement and budget review | Defendable recurring spend framing | Subscription-led or hybrid with a recurring base | Can Finance explain annual spend logic without manual reconciliation workarounds? |
Treat this as a starting heuristic, not a fixed rule. Model choice should reflect product, market, competition, and revenue drivers, not intuition alone.
Use simple execution rules so teams apply the model consistently:
Stress-test the design before scaling. The tradeoff is simple: overly rigid pricing can limit growth, while overly loose pricing can make revenue unpredictable. Also run a scale sanity check. If the economics do not work at 10 customers, they are unlikely to work at 1,000.
Finally, define a clear review process for pricing exceptions so margin impact, invoice explainability, and implementation complexity are checked before non-standard deal terms are approved. Before locking your segment defaults, run your own pricing scenarios in the Pricing Calculator.
Hybrid pricing is most predictable when the base fee covers stable access and usage charges track variable cost drivers. If a customer cannot estimate next month's bill from a few visible inputs, simplify the offer before scaling sales.
Use the base subscription for repeatable, low-variance value, and use metered lines for cost-sensitive activity. A workable split is platform access and other recurring value in base fees, with transaction processing, FX, payout activity, and other volume-linked costs in usage fees.
| Charge or fee | How it's treated | Note |
|---|---|---|
| Platform access | Base fee | Repeatable, low-variance value |
| Other recurring value | Base fee | Placed in base fees |
| Transaction processing | Usage fee | Cost-sensitive activity |
| FX | Usage fee | Cost-sensitive activity |
| Payout activity | Usage fee | Cost-sensitive activity |
| $2 per monthly active account | Example user fee | Monthly active account = one that received payouts in that month |
| 0.25% + 25¢ per payout sent | Example user fee | Example fee when the platform handles pricing |
Map charges to how costs actually land. In Stripe Connect's "you handle pricing" model, the platform is responsible for Stripe processing fees and can charge users its own fees. That can include fees such as $2 per monthly active account and 0.25% + 25¢ per payout sent. Stripe defines a monthly active account as one that received payouts in that month. If payouts drive cost, hiding that signal inside a flat fee can erode margin as usage grows.
Write overage and top-up rules in plain language customers can forecast. Example structure: your plan includes platform access; if included usage is exceeded or payouts are sent, additional charges apply per defined meter and rate in the order form.
Keep the structure consistent across contract terms, product UI, and billing configuration. Keep each variable line tied to one meter, one unit, and one billing-timing rule so usage maps cleanly to invoice lines.
Run a sample-invoice check before launch with low-, expected-, and spike-usage scenarios for the same account. If Sales, Finance, and Support cannot all explain each line from the same usage data, simplify the design.
Make usage visible before invoice close. Show current-period usage in product, label billing units clearly, and send pre-bill alerts when accounts approach caps, step-ups, or meaningful overage bands.
This matters most for high-variance accounts. Stripe notes that charges are applied to the platform at month-end based on total payouts sent. If customers only see usage after month close, even contract-allowed charges can feel surprising.
State caps, step-ups, and country-specific fee variability up front. This is critical when economics depend on payment-method mix, international volume, or currency conversion.
Stripe's Managed Payments examples highlight this variability. 3.5% per successful transaction is charged in addition to standard processing fees. Additional charges can apply for subscription payments, and country pricing pages can override listed local-method fees. Do not present one global rate card as fixed when underlying costs can vary by country or conversion needs.
Final check: can the customer estimate next month's charge range from current usage, included amounts, and one clear overage rule? If not, reduce plan variants, reduce fee types, or move more cost into the base fee until they can.
For a step-by-step walkthrough, see How to Expand Your Subscription Platform to APAC: Payment Methods Currency and Regulatory Market.
A pricing model is rollout-ready when each charge can be enforced in product, billed cleanly, and traced in reconciliation with minimal manual fixes. Before broad rollout, lock a control sequence: entitlements, invoice architecture, ledger mapping, then validation checks.
Define entitlements before invoice logic. If plans include baseline access, premium workflows, or usage caps, enforce those states in the product layer, because billing data alone may not reflect what a customer should be able to use.
For each plan, document four points: what is included, what is capped, what triggers overage, and what blocks access. Then keep those rules aligned across contract terms, billing configuration, and product logic. Tools that parse contract terms and meter usage in real time only help when the source rules match.
Verification point: test one in-limit and one over-limit scenario per plan. If Support must manually override access, the plan is not rollout-ready.
Build invoices from discrete charge types and map each charge to audit evidence. Each billed amount should trace from customer action to provider reference to ledger impact.
Use a standard evidence pack for every charge type:
This addresses two common failure modes: pricing logic split across app code, billing rules, and internal docs, and invoices that go out late or wrong. If you cannot trace a subscription fee or overage charge through these artifacts, do not expand rollout.
Encode eligibility and market constraints in plan logic, not support-side exceptions. If a plan depends on access to certain flows, markets, or payment features, enforce eligibility before activation.
This keeps Sales, Product, and Operations aligned. Pricing decisions shape downstream product priorities and sales motion. When gating lives outside plan logic, teams can sell ineligible configurations and Operations absorbs preventable exceptions. Use this order: eligibility check, entitlement grant, billing activation, then usage metering.
Validate tax and reporting interactions before launch, especially when monetization changes affect who is billed, what is reported, or which records need documentation. Review how tax and required reporting fields flow through billing and exports before changing plan structure.
Do not wait for month-end to find missing tax handling or missing documentation status fields. Integrations across CRM, payments, and accounting help only if required reporting fields are captured upstream.
Run one pre-launch reporting test pack: generate a sample invoice, confirm expected tax fields, and verify customer records contain the status fields Finance needs.
We covered this in detail in How to Expand Your Subscription Platform to Europe for Payment and VAT Readiness.
Once your charge logic is enforceable and reconcilable, roll out in phases, not all at once. Pilot first, then move toward General Availability only after the pilot clears explicit checks, because payment-flow steps are interconnected and issues can surface downstream in costs or retry outcomes.
| Rollout step | What to cover | Gate or action |
|---|---|---|
| Pilot cohort | Different payment-flow patterns and a reusable baseline | Make pre-pilot and pilot results directly comparable |
| Phase gates | Authentication outcomes, payment-rail cost impact, and failure-and-retry behavior | If one degrades materially, pause expansion and investigate |
| End-to-end review | Customer action through payment outcome and retry path | Catch tradeoffs that isolated revenue metrics can miss |
| Rollback | What pauses rollout, what gets reverted first, and evidence required to restart | Pause expansion first, then diagnose and fix with a clear owner and response path |
Start with a pilot cohort that reflects different payment-flow patterns, not just your most stable accounts. Before launch, define a baseline you can reuse so pre-pilot and pilot results are directly comparable without manual rebuilds.
Set phase gates before go-live and treat them as release criteria, not dashboard noise. At minimum, define checks that cover end-to-end flow dependencies, including authentication outcomes, payment-rail cost impact, and failure-and-retry behavior. If one degrades materially, pause expansion and investigate before adding more customers.
Review checkpoints end to end, not as isolated metrics. Authentication choices, rail selection, and failure handling are connected, so each gate should include traced examples from customer action through payment outcome and retry path. This helps catch tradeoffs that isolated revenue metrics can miss.
Define rollback triggers and decision ownership before launch day. Document what pauses rollout, what gets reverted first, and what evidence is required to restart. If a trigger fires, pause expansion first, then diagnose and fix with a clear owner and response path.
A common mistake is treating payment pricing as one generic SaaS pattern. Stripe separates recurring billing, usage-based billing, and sales-negotiated contracts, so treat them as different charging problems and validate your model before rollout.
Do not copy a packaging template without testing your own charge logic. If you cannot trace charges from customer activity to invoice lines to revenue management output on real accounts, the packaging is not ready. Stripe's model split is the practical cue. Recurring, usage-based, and sales-negotiated contracts need explicit design, not just a different invoice layout.
Verification point: rebuild a recent month for a small sample of accounts and confirm the proposed plan reconciles cleanly without manual fixes.
Keep variable usage explicit, even when you sell a recurring fee. A subscription is still a recurring fee to use the software, and Stripe flags billing and revenue management as a challenge area in subscription models. Define what is included, and make overage logic visible before invoicing so customers can map contract terms to expected charges.
Recover in controlled cohorts and measure each change. Customer churn is a documented challenge area in subscription models, so adjust terms in planned groups with clear before-and-after views of usage and invoices, then expand only when the changes are working. That keeps corrections faster and easier to verify.
Tighten contract mechanics before defaulting to discounts. Make commitments and overage terms straightforward to explain and forecast so commercial review is easier and less ambiguous. If you need a mechanics reference, Hybrid Pricing Models: How to Combine Subscription Fees Plus Usage Charges on a Single Invoice is the right next read. Related reading: How to Build a Subscription Billing Engine for Your B2B Platform.
Treat pricing as a monthly operating discipline, not a one-time launch decision. If you do not review margin, disputes, and exception drift together, small concessions can compound over time.
Review a compact scorecard every month. Track realized margin by cohort, expansion revenue share, churn or retention by plan, invoice disputes, and reconciliation effort hours. The goal is to confirm your model is still converting usage and service cost into durable revenue.
Verification point: trace one cohort to source records each month. If margin moved, you should be able to explain whether usage mix, discounts, disputes, or manual billing fixes caused it.
Segment the review and test for pricing-value mismatch. Compare results by sales motion and product mix. Look for where one segment is creating lower margin, higher dispute volume, or heavier Finance effort than your plan assumes.
Do not treat topline growth as proof the model is healthy. If a fast-growing slice also raises invoice friction and reconciliation work, adjust pricing or entitlements before the pattern spreads.
Recheck compliance and tax dependencies each quarter when coverage changes. If your scope includes compliance or tax assumptions, assign a named owner and confirm those assumptions against current official guidance or advisor input before carrying them forward.
For FEIE, apply the IRS physical presence test as written for U.S. citizens and U.S. residents: 330 full days during any period of 12 consecutive months. A full day is 24 consecutive hours, midnight to midnight, and the 330 days do not have to be consecutive. Recalculate from travel records and review the IRS annual Revenue Procedure for any country waiver. Missing 330 days is still a miss, including cases involving illness, vacation, family issues, or employer orders.
Keep a single decision log for pricing exceptions. Record the account, requested exception, approver, expected revenue upside, modeled margin impact, and renewal date. If an exception has no clear economic rationale and no review date, treat it as likely long-term margin erosion.
A defensible pricing model is one you can defend in sales calls, review against total cost to sell, and trace when a bill is challenged.
Name the dominant cost drivers and usage variance for each cohort. Do not collapse unlike patterns into one average, and include the cost buckets that materially affect outcomes, for example web checkouts, in-app purchases, and developer account fees.
Use a simple decision-making tool so model choice is explicit and repeatable. Pick the structure that matches how each segment buys and uses the product, rather than copying market packaging.
Keep the base tied to durable value, meter what actually varies, and make overage logic clear enough to estimate before invoicing. Do not assume benchmark fee percentages or break-even thresholds without your own data.
Each charge should trace from product event to invoice line to accounting output. If those outputs are machine-readable but hard for humans to interpret, treat that as a launch risk, not a documentation detail.
Test in a controlled cohort, define rollback criteria up front, and scale only when your operating metrics and margin behavior stay within your expected range.
Review realized outcomes regularly, track pricing exceptions with ownership and rationale, and retire exceptions that do not hold up economically.
When you move from pricing strategy to implementation controls, use the Gruv Docs to map charges, events, and reconciliation flows.
Transaction-fee pricing can be useful when activity is uncertain and you want charges to move with processed transactions. That ties pricing more directly to transaction volume instead of relying only on a fixed fee. Recheck the model as customers scale, because transaction-fee exposure can erode profitability and, in cited examples, fee levels vary widely across services (0% to 10%+).
Hybrid pricing can work well when you need baseline predictability and a way to recover variable usage costs at the same time. It combines fixed and usage-based elements instead of forcing one model across all customer patterns. Validate the split with segment-level usage data and customer research before rollout.
This evidence pack does not define a universal base-versus-overage formula. Use customer research and segment-level usage data to decide which components belong in the base and which should scale with usage. Whatever split you choose, make sure your billing setup can handle multiple pricing models and real-time usage tracking so charges stay clear.
Exact committed-minimum structures and quantified TCV effects are not established in this evidence pack. Treat minimums as a deal-design choice and model them against total cost of ownership, not headline subscription price alone. If economics depend on assumptions, make those assumptions explicit during negotiation.
Make usage and pricing mechanics visible before invoices are issued. Operationally, that requires billing that supports multiple models and tracks usage in real time. An end-to-end billing system with CRM and ERP integration helps keep expansion usage billable while reducing surprise.
There is no single benchmark in this evidence pack that proves success. Judge performance using segment-level usage data, customer feedback, and a full cost view that includes subscription, transaction fees, processing charges, and payout-timing cash-flow effects. If those inputs drift, revisit pricing before scaling further.
There is no universal monthly, quarterly, or annual cadence in this evidence pack. Recalibrate when the underlying cost shape changes materially, including changes in usage patterns, pricing mix, or payout timing that affect cash flow. Use fresh segment data and customer research instead of carrying old assumptions forward.
They compare only the monthly subscription price. That misses transaction fees, payment processing charges, and payout-timing cash-flow effects that drive total cost of ownership. The result can be choosing a lower headline plan that costs more in practice, such as the cited $39/month + 5% versus $149/month + 0% tradeoff once volume grows.
Yuki writes about banking setups, FX strategy, and payment rails for global freelancers—reducing fees while keeping compliance and cashflow predictable.
Educational content only. Not legal, tax, or financial advice.
Move fast, but do not produce records on instinct. If you need to **respond to a subpoena for business records**, your immediate job is to control deadlines, preserve records, and make any later production defensible.
The real problem is a two-system conflict. U.S. tax treatment can punish the wrong fund choice, while local product-access constraints can block the funds you want to buy in the first place. For **us expat ucits etfs**, the practical question is not "Which product is best?" It is "What can I access, report, and keep doing every year without guessing?" Use this four-part filter before any trade:
Stop collecting more PDFs. The lower-risk move is to lock your route, keep one control sheet, validate each evidence lane in order, and finish with a strict consistency check. If you cannot explain your file on one page, the pack is still too loose.