Skip to main content
2,200+ service businesses benchmarked. Do you know your gross profit per labor hour? See where you stand →
Level

Software collection playbook

Roofr: trace accepted options to invoices

Chosen invoice scope versus quote options.

By Sam Yang · Updated

Which proposal option became an invoice, and which payment became cash?

Use the bulk files to establish coverage, then identify the accepted option and inspect only the native details needed to connect invoicing and payment. A proposal total and a bank receipt answer different questions.

Evidence basis: Saved invoice/payment export sequence and rendered-grid observations. Missing fields describe the observed files, not all current Roofr exports.

Verify current region, plan and beta eligibility, then the supported direction and objects. A successful export does not certify integration coverage.

Several proposal alternatives belong to one opportunity

Identify the accepted option before counting sold work. Adding all alternatives would count choices the customer did not buy.

The payment file lacks the identity needed for settlement matching

Keep the payment as source activity and obtain the required native detail or bank evidence. Do not manufacture a settlement ID from row position.

Use supported API or native report access for the required scope. A permitted browser session can collect a specific gap. Neither route proves reconciliation or complete costs.

Put the evidence to work

How much work was actually accepted, how much was invoiced, and how much reached the bank?

Those are three stages of the same chain, not interchangeable totals. Keep proposal alternatives out of sold-work totals, trace the accepted option to its invoice, and trace received payments to settlement evidence. A payment schedule is a request for future cash, while a due date is a collection deadline. Neither establishes a bank receipt.

Follow an accepted option to billing
  1. Confirm the intended team and account entitlement. Current product and pricing pages describe a beta QuickBooks Online route; the pricing page restricts it to US businesses and excludes Desktop.
  2. Retain each proposal identity, its alternatives and the accepted option. Use explicit acceptance evidence instead of treating every priced option as a sale.
  3. Using the October 6 saved sequence, open Invoices > Export to CSV > Export all and retain the complete original population before deriving a period view.
  4. Read the export’s actual columns. If job linkage, issue date or status is absent, inspect only the native detail required to establish that link. A row’s position cannot stand in for a source identifier.
  5. Compare accepted work with invoice value and document approved changes separately. Use the chosen invoice-date or other explicitly defined billing basis, not due date by default.

Bring to the review: A proposal-option-invoice chain with accepted value, invoiced value, changes and unlinked records.

Then decide: Investigate accepted but uninvoiced work with the billing owner. Decide the accounting recognition separately from proposal acceptance.

Separate payment requests from collected and settled cash
  1. Collect Payments > Export to CSV under the saved procedure and retain payment IDs, invoice references, amounts and dates that the file actually supplies.
  2. Keep scheduled instalments separate from received or recorded payments. A September official masterclass explains that unreceived scheduled payments do not become QBO export options.
  3. Inspect native payment or financing detail for the missing relationship. Preserve the displayed state; a Not funded label is not proof of bank settlement.
  4. Collect settlement or processor evidence and bank activity in the same currency and cutoff. Explain fees, timing, reversals and amounts still pending.
  5. Return one row per identified payment with its settlement state. Do not press Record payment, Create payment, Send, Edit or sync controls while gathering evidence.

Bring to the review: A receipt-to-settlement bridge with gross payment, fees, expected net, actual bank occurrence and unresolved timing.

Then decide: Send unsupported links to the owner for review. Report cash only on supported bank evidence; keep scheduled collections visible as a separate follow-up queue.

Which collection route answers this question?

Choose the route for the missing evidence and the access available in your account. The comparison below distinguishes documented coverage from coverage that still needs checking.

Supported integration

What it supplies
Current Roofr product/pricing references describe QBO exports for contacts/catalog items, invoices and payment information, with beta and regional eligibility.
What still needs proof
This review has not verified a general-purpose financial read API or the account’s available beta enrollment. It does not establish settlement reconciliation coverage.

Choose it when: Use the supported entitled connector for its documented objects after testing an existing invoice/payment trail; avoid promising unrestricted two-way coverage.

Native CSV export

What it supplies
Saved collection provides bulk invoice and payment CSVs. Complete originals can establish the retained source population.
What still needs proof
Observed files lacked some job/invoice and settlement fields. That is a property of those observed files, not a claim about every current export.

Choose it when: Use bulk files for coverage and inspect current headers before selecting detail supplements.

Permitted browser detail

What it supplies
Accepted options, native invoice context and payment states can supply relationships absent from a collected file. Saved grid capture keeps horizontal columns for the same rows.
What still needs proof
Row order is not identity, an empty settlement panel is not proof no settlements exist, and rendered grids need full population checks.

Choose it when: Use read-only native detail for a named missing link; capture all needed columns before moving to the next rows.

Reproduce the diagnostic

One accepted option, one deposit, one settlement

All records and amounts below are fictional teaching inputs. This example demonstrates the calculation, not a customer outcome or a reproduced software defect.

The two alternatives sum to $22,000, but accepted work is $12,000. The scenario has a $3,000 received deposit and a deliberately fictional $90 fee, leaving $2,910 settled. The $9,000 difference between invoicing and this deposit is still unpaid in this simplified example. Fee amounts are invented, not a Roofr price quote.

What the CSV columns mean
  • option_id: Fictional proposal option
  • accepted: Explicit teaching selection
  • amount: Fictional USD
  • kind: Cash bridge component
All options
22000 USD
A choice total, not sold work
Accepted value
12000 USD
Only the selected option
Expected net settlement
2910 USD
Received deposit less fictional fee
Unpaid invoice portion
9000 USD
Invoicing less received deposit, with no credits/refunds assumed
Inspect roofr-options.csv
option_id,accepted,amount
OPTION-DEMO-A,no,10000
OPTION-DEMO-B,yes,12000
Download this CSV
Inspect roofr-cash.csv
kind,amount
invoiced,12000
received,3000
fee,90
settled,2910
Download this CSV

Next decision: Prove actual invoice applications and settlement evidence before carrying this bridge into an accounting or cash report.

Run the example locally

Save the CSV files, expected-results.json and reproduce.mjs in one folder. With Node.js installed, run the command below. It calculates the checks from the CSV bytes and rejects a changed input or expected result.

node reproduce.mjs expected-results.json

No software login, customer records or API key is required.

When the result does not make sense

Sold-work total includes every proposal option

Check: Check whether alternative options share one proposal and only one was accepted.

Resolve the question: Rebuild the accepted-value population from explicit selection evidence and retain alternatives as choices.

Year-to-date sales changed after filtering by due date

Check: Compare due, issue and acceptance dates, then state the requested financial basis.

Resolve the question: Partition by the relevant billing date. Treat due date as a collection attribute rather than substituting it for revenue recognition.

Roofr payment exceeds the bank deposit

Check: Trace the exact payment, fees, settlement date and any financing state or reversal.

Resolve the question: Build a gross-to-net timing bridge and hold unverified settlement links. Equal amounts alone do not identify the receipt.

Where automation earns its place

Good work for automation

  • Maintain a proposal-option-invoice chain and flag accepted work missing billing evidence.
  • Build payment settlement exception packets from retained CSVs and approved native detail.

Keep a person on these decisions

  • Resolve accepted changes and accounting recognition.
  • Approve payment, refund or sync actions and adjudicate financing or disputed settlement states.

References behind these workflows

Product documentation supports the specific scope stated beside each source. Level's diagnostic methods and fictional calculations remain distinct from vendor capabilities.

Explore the financial diagnostic examples

Collect and verify the population

Accepted option and invoice
Preserve the relationship if available; inspect detail where the observed CSV does not supply status, issue date or job linkage.
Invoice and payment CSVs
Export the complete native population before deriving the requested period; due date alone is not an earned-revenue cutoff.
Rendered grid and bank evidence
Capture all horizontal fields for the same rows. The observed Not funded label and an empty settlement screen do not establish settled cash or the absence of settlements.

Verify current integration eligibility. Retain accepted option, invoice and payment identities with the selected status/date filters; compare source invoices and payments with the books.

Dated collection sequence

Dated saved collection procedure reviewed October 6, 2026. Verify the current account, interface, permission and available reports. Menu names may differ.

  1. Verify the rendered company and intended team.
  2. Open Invoices, then Export to CSV > Export all. Retain the original file before deriving a selected-period view.
  3. Open Payments > Export to CSV and retain the original payment file.
  4. Inspect actual columns and population. The observed files omitted some invoice/job and settlement fields, so retain necessary native detail separately.
  5. If collecting rendered rows, capture horizontal sections before scrolling vertically and compare retained rows with the declared grid population, excluding its header. Row position is not a native transaction identity.
  6. Do not use Send, Create payment, Record payment, Edit, Delete or sync controls during collection. An empty settlement screen cannot establish that settlements do not exist.

Evidence acceptance checklist

  1. Confirm the account entitlement before assuming a QBO connection is available.
  2. Identify the accepted proposal option rather than summing alternative options.
  3. Keep the resulting invoice and payment identities for comparison with the books.

Fictional collection example

A fictional proposal contains two alternative roof options and one accepted selection. The alternatives are choices, not two won jobs. Return the selected option and its invoice trail. A missing invoice link stays an exception rather than another inferred sale.

Invented teaching scenario, not a customer result or a reproduced vendor defect.

Capture the setup with the evidence

  • Company, legal entity or account, report name, period, basis, currency and timezone.
  • Selected filters, status, page count, original record identifiers and control totals.
  • Collection time, source route and authorized role. Record browser and automation versions when using a browser.
  • Original files and exceptions. Keep credentials, customer identifiers and financial artifacts private.

A browser version helps reproduce an interface issue. It does not validate the financial conclusion.

Pitfalls and stop conditions

Alternative proposal options are not separate won jobs. Confirm the exact product and integration entitlement before using a workflow.

How a plausible answer can go wrong

Counting every proposal option as booked work and filtering invoices by due date can produce a polished year-to-date number with the wrong population. Complete rows do not fix that definition.

Stop if account identity, permission, cutoff or population is uncertain. Return the missing evidence for review. Do not fill the gap with an invented record, a balancing entry or an assumed zero.

Read-only AI collection prompt

Replace the bracketed scope before use. This prompt collects evidence; it does not permit edits, approvals or accounting execution. Requesting an emailed report is a separate account action and requires explicit authorization.

Collect read-only evidence for Roofr to answer [financial question]. Confirm [company], [account/entity], [period], [basis], [currency] and [allowed reports]. Verify current integration eligibility. Retain accepted option, invoice and payment identities with the selected status/date filters; compare source invoices and payments with the books. Retain original files, complete record IDs, counts, filters, collection timestamp and exceptions. Alternative proposal options are not separate won jobs. Confirm the exact product and integration entitlement before using a workflow. Stop if the source or scope is uncertain. Do not post, match, reconnect, delete or change settings. Return the evidence for financial review; do not claim the books are correct. Do not approve, submit payroll, pay, transfer, refund, send messages, invite users or accept terms. Stop at any login, MFA or credential prompt and hand back to the account owner. Store files only in [approved private location]. Do not paste customer artifacts into public tools. Use only preauthorized collection actions. Request an emailed report only when its delivery is explicitly authorized; otherwise ask the account owner to supply the file.

Next decision

What does the evidence support?

Which accepted work was invoiced, which source payments are identified, and which payments have bank settlement evidence? Keep each unanswered link visible before reporting cash or sales.

Compare the same population, identities and cutoff. Keep unsupported costs or settlements visible before using the result for pricing, cash or close.

Open the financial acceptance guide →

Sources and scope

Base product-reference scopes were reviewed . The collection procedure retains its own review date in the dated sequence above. Individual source rechecks are dated with their citations. Operator decision guidance was reviewed 2026-10-07. The references below support their stated product scope, not every observed interface detail. It is not a vendor capability certification, a measured customer result or an independently reconciled account. Verify current features and entitlement in the account you use.

Content revision history