Stop Entering the Same Number Twice
Learn how reviewed cash, payroll, commitments, plans, and scenarios can inform connected financial views without flattening their meaning.
Updated
Duplicate financial entry is more than an efficiency problem. When the same hire, receipt, commitment, or cash balance is copied into several files, each copy can acquire a different amount, date, definition, or status. The team then spends the review reconciling versions instead of examining the decision.
Direct answer: A connected financial planning system should let one reviewed input inform every relevant financial view without forcing the same number to be manually re-entered. That does not mean every module becomes one number: cash, revenue, payroll, commitments, budgets, actuals, and scenarios keep distinct meanings.
What duplicate financial entry costs
Re-entering a value takes time, but the larger cost is loss of context. One sheet may use a hire's offer date, another the start date, and another an averaged monthly cost. A receipt may be recorded as cash in one file while another still shows the full expected amount. A contract can appear monthly in a budget but disappear from the month its annual payment is due.
Those differences are not always errors. They may represent distinct financial meanings. The problem begins when the copies are unlabeled or maintained independently, so nobody can tell whether a difference is intentional.
Connected does not mean flattened
Recorded cash shows money held or movement that has occurred. Revenue and deals describe commercial activity. Payroll describes team cost. Commitments describe approved obligations and timing. Budgets describe a plan. Actuals describe recorded outcomes. Scenarios describe conditional hypotheticals.
A connected view can place these layers in the same decision context while keeping their states visible. Expected customer cash should not become received cash. A commitment should not become a paid transaction before payment. A scenario should not overwrite the current plan.
One change can inform several relevant views
Consider an approved team member with an October 1 start date and $8,000 monthly team cost. The reviewed input belongs first with the team and payroll context. It may also affect the relevant budget periods, modeled operating outflow, and runway planning from October.
The useful connection is not seven copied cells. It is one traceable input appearing where the decision requires it. Past actuals remain unchanged. Bank cash is not reduced before a payment occurs. If the hire exists only in a scenario, the current plan remains intact.
- Reviewed input: team member, October 1 start, $8,000 monthly cost
- Relevant context: team and payroll view, budget periods, modeled outflow
- Planning effect: changed runway context from the effective month
- Preserved boundaries: no rewritten actuals, invented cash, or promoted scenario
Current facts and hypothetical scenarios need separate states
A hiring idea can be tested before approval. In that case, the $8,000 belongs only in the scenario. If the company later approves the role and start date, the current plan can be updated through the appropriate workflow. That transition should be explicit rather than inferred from a what-if model.
The same rule applies to revenue. A possible deal may inform a scenario without becoming forecast revenue. Forecast revenue may inform planning without becoming received cash. When a receipt lands, only the amount received should change realized cash.
Source-of-truth boundaries still matter
Connected planning does not eliminate source systems or review responsibilities. Treasury information supports the recorded cash context. Team records support payroll planning. Deals and receipts support revenue and cash-receipt context. Commitments support future obligations. Budgets, forecasts, and scenarios each retain their own purpose.
The source behind a number should remain identifiable. A user should be able to ask whether the value was entered directly, imported through a supported workflow, calculated from defined inputs, or introduced as a planning assumption.
Reconciliation still has its own job
Bank reconciliation is an accounting control that compares cash records with the bank and the accounting books. A planning system can use reviewed cash information, but it does not replace that control or turn a planning balance into reconciled accounting truth.
A statement or supported provider import may help stage or confirm information for review. The approval, mapping, duplicate checks, and source boundaries still matter. Treasury documentation explains the recorded-account workflow, while Deals and Revenue documentation explains the distinction between deal context and receipts.
Activity history is not an accounting ledger
RunwayCal's Treasury activity context can help explain recorded inflows and outflows inside the product. That history can support planning review and traceability. It should not be presented as a general ledger, a replacement for double-entry accounting, or the complete financial history of the company.
Financial Statements also has a defined reporting role. Connected product surfaces can use related information without claiming that every surface is the accounting source of record.
A worked change-propagation example
| Event | State | Relevant effect | Boundary preserved |
|---|---|---|---|
| New team member | Approved, starts October 1 | Team cost and relevant future planning periods | Past actuals and current bank cash unchanged |
| Expected customer amount | Deal or collection context | Revenue planning and expected timing | Not treated as cash received |
| Partial customer receipt | Actual receipt reviewed | Realized cash changes by amount received | Remaining expected amount stays distinct |
| Hiring scenario | Hypothetical | Conditional outflow and runway comparison | Current plan stays intact |
The customer example shows why connection and flattening are different. A $60,000 expected amount followed by a $25,000 receipt does not mean the full $60,000 landed. The realized-cash view changes by $25,000, while the remaining expectation requires its own status and review.
Questions a connected system should answer
- Where did this number come from, and who reviewed it?
- Is it recorded, expected, planned, committed, paid, or hypothetical?
- Which date controls its effect?
- Which financial views should use it, and which should not?
- What changed from the previous value or state?
- Can the result be traced back without rebuilding the calculation?
- Does an accounting or reconciliation control still need to occur elsewhere?
Spend less time rebuilding the financial picture.
Bring reviewed inputs into one connected planning context while preserving what each financial state means.
Explore RunwayCal