Label a volume estimate before it enters the application

Read the field as a defined measurement

Copy the exact label, explanatory text, unit and period from the form. Monthly volume may be ambiguous unless the provider identifies whether it means card processing, all sales, a past month or an expected future month. Average order size also needs a defined population: all orders, paid orders, or payment transactions can produce different answers. Resolve those distinctions before calculating.

Write the entity, channel, currency and start/end dates beside the field in your working note. Keep amounts in different currencies separate unless the provider specifies how to convert them. Do not replace a request for historical card processing with total business revenue merely because that is the only available figure. Your note should explain exactly what the number measures so it can travel with the application.

Calculate from the records that actually exist

For a historical total, identify the qualifying records and add their amounts using the provider’s stated definition. For a historical average, divide the amount for that same set by the matching count. An order average and a payment-transaction average are only interchangeable if the underlying records make them so. Document how refunds, unpaid orders, split payments and shipping or tax amounts were treated whenever those affect the requested measure.

A partial operating period remains a partial period. State its actual dates and count rather than describing it as a complete month. Scaling a short period into a future month produces a forecast; it does not create missing history. Likewise, the current catalog price alone does not establish an average ticket because it does not show the mix and quantities actually purchased.

Zero is appropriate only when the defined measure truly has no qualifying activity over the relevant period and the provider’s instructions permit that representation. An inaccessible record, a period before trading began, or a field asking for a future expectation needs its own explanation. With no qualifying orders, an average calculated by dividing by the order count is undefined, not a measured zero.

Make a forecast reproducible and visibly prospective

When the field genuinely asks for expected volume, keep the assumptions beside the estimate: the future period, the expected count of qualifying payments or orders, and the amount basis. Derive those inputs from available business records and explicit planning assumptions. Current prices can support an amount assumption; actual commitments can inform expected activity while still being subject to their terms. Inventory capacity or an unsigned expression of interest is not completed demand.

An expected count multiplied by an expected average amount is a possible calculation only when both inputs use the same population, currency and period. If there are several order groups, calculate each from its own documented count and amount assumptions before summing. Do not add a growth percentage without a stated baseline and rationale. With no baseline, describe the expected future amount and its assumptions rather than inventing a growth history.

A useful basis note contains the prospective label, future dates, relevant entity and channel, source dates, calculation and unsettled assumptions. If an assumption cannot be supported well enough to put in that note, leave the estimate unresolved. This worksheet supplies a way to explain a forecast; it does not supply a default number or require a provider to accept your method.

Keep the qualification attached when the form allows only digits

If the form has a companion notes field, use it to identify the exact numeric field and state whether the entry is historical or prospective. If there is no place for that qualification, record the field label and limitation and ask how the provider wants an estimate, absent history or unknown amount represented. Do not enter a dummy amount simply to reach the next screen, and do not assume that an unexplained zero communicates no history.

Retain the provider’s instruction with your basis note and the version of the application it concerns. An instruction to enter an estimate answers the entry-format question; it does not turn that estimate into completed processing or approve the business. If the provider requires a figure you cannot support and offers no accurate way to proceed, the field remains unresolved.

Stripe’s business-information and account-setup documents explain verification and possible requests for additional information. They do not publish a universal estimate formula or say that any forecast will be accepted. The asking provider controls its document requirements and underwriting. Prism can help organize the figures’ labels and the unresolved questions in a scoped processing-preparation consultation. Scope, responsibilities, fees and terms are discussed before work; keep financial records and private account details out of the public inquiry.

Estimate-field labeling table

Complete this before transcribing a number into a required field. Each amount needs a status, population, period, currency and basis. If the form cannot carry that meaning, the completed table identifies the exact entry question to send to the provider; it does not justify a guessed value.

Worksheet entries are not submitted by Prism’s worksheet and are not saved by the site. Use record types, availability, anonymized observations, or match/mismatch results. Do not enter government identifiers, customer names or addresses, customer messages, receipt-access links, card or bank details, passwords, or keys. Send sensitive documents only through the provider’s verified secure channel.

These are temporary notes. Leaving or reloading this page may clear them. Worksheet entries are not sent automatically. If you copy notes into the consultation message and submit the form, Prism receives them as part of your request.