Stripe
Stripe is a third-party payments and billing technology platform whose available capabilities depend on the Stripe products and configuration a business uses.
A Stripe payment, invoice, subscription, refund, dispute, fee, payout, balance, accounting revenue amount, MRR value, and bank deposit are related but distinct records and events.
Use Stripe data according to the specific object and state. A successful charge is not automatically recognized revenue or the net cash deposited in a bank, and a subscription record is not automatically the company’s approved MRR policy.
Move supported Stripe records through a review boundary
Provider data keeps its source identity until a supported mapping or linked event is accepted into RunwayCal.
- 01Supported Stripe data
Customers, subscriptions, charges, invoices, and balance context within the current connection
- 02Read and validate
Provider identity, supported fields, and duplicate protection are preserved
- 03Review boundary
Suggested deal or receipt mappings require review; narrowly supported linked events follow their defined path
- 04Accepted RunwayCal record
Approved data enters the owning deal, receipt, or Treasury context
- 05Planning context
Revenue, cash, and runway surfaces answer their separate product questions
What is Stripe?
Stripe provides technology for businesses to accept and manage payments and, depending on the products configured, handle billing, subscriptions, invoices, customer records, balances, payouts, refunds, disputes, and other payment operations. The exact records available depend on the Stripe account, geography, products, payment methods, and integration design.
Those records do not collapse into one financial state. A payment can be authorized, captured, refunded, disputed, or subject to fees. Funds can sit in a Stripe balance before payout. A payout can group multiple transactions and reach the bank on another date. Revenue recognition follows the applicable accounting policy, and MRR follows the company’s documented recurring-revenue policy.
Stripe should therefore be treated as a source of provider records, not a universal accounting ledger or direct statement of bank cash. Reconciliation connects the provider, accounting, and bank evidence without relabeling one as another.
What the current RunwayCal connection reads
The current product uses a restricted or secret Stripe API key to read supported customer, subscription, charge, invoice, and balance context. Suggested deal and receipt mappings remain reviewable. Provider identifiers stay attached so accepted records can be traced and duplicate paths can be guarded.
Refresh and write boundaries
RunwayCal does not write financial changes back to Stripe. Supported linked events and a narrow Stripe Balance refresh path are provider-specific behaviors, not evidence of a universal automatic sync, bank feed, or accounting close. Revoking the key in Stripe ends provider access fully.
Keep these states separate
Payment or charge
A provider event that can precede fees, refunds, disputes, payout, and bank settlement.
Invoice or subscription
Commercial and billing context that does not by itself prove collection or recognition.
Stripe balance and payout
Provider-held funds and transfer events under Stripe’s account and payout mechanics.
Bank cash
The amount that reaches the relevant bank account after settlement and any other movements.
Revenue and MRR
Accounting and operating measures governed by separate policies.
Why it matters
Payment-provider data can improve traceability and reduce manual re-entry, but overstating the connection can create worse financial decisions. A charge, payout, bank deposit, invoice, and recognized revenue amount can legitimately differ.
Reviewing the source object, state, fees, refund or dispute status, payout grouping, and accepted RunwayCal mapping helps keep planning inputs explainable.
What goes into it
- A supported Stripe account and restricted connection
- Provider object type, identifier, amount, currency, and status
- Fees, refunds, disputes, balance, and payout context where relevant
- A reviewed destination in RunwayCal for suggested mappings
- Separate accounting, recurring-metric, and bank-reconciliation policies
Illustrative payment path
A customer pays a $1,000 Stripe invoice. The provider records the payment and later includes it with other activity in a payout after applicable adjustments. The bank receives the net payout on a later date. RunwayCal preserves the supported provider identity and review path; the accounting system and revenue policy determine recognition.
How RunwayCal helps
RunwayCal supports a reviewed Stripe-to-RunwayCal path for customers, subscriptions, charges, invoices, and balance context. Suggested deal or receipt mappings require human review, while narrowly defined linked events and Stripe Balance behavior follow their supported product path.
RunwayCal does not initiate charges, write changes back to Stripe, perform general bank reconciliation, or decide accounting revenue recognition.
Common mistakes
- 1Calling Stripe the automatic system of record for MRR or recognized revenue in every business.
- 2Treating a successful charge, Stripe balance, payout, and bank deposit as the same amount and date.
- 3Claiming live, universal, two-way, or general bank synchronization from the narrow supported behavior.
- 4Assuming every suggested mapping enters RunwayCal without review.
- 5Ignoring fees, refunds, disputes, credits, currencies, and payout grouping.
Get the Financial Clarity Newsletter
Practical tips on cash flow, runway, and financial decisions for founders, business owners, CFOs, investors, and board members. Free, weekly, no spam.
Review Stripe records before they enter the plan.
Keep provider events, accepted RunwayCal records, revenue policy, and bank cash in their correct states.
Explore the Stripe integration