Which deals actually made money?

Deal profitability requires your CRM, accounting system, and delivery records together. HubSpot shows the sale, QuickBooks shows invoices and payments, and time tracking plus payroll show delivery costs. Match those records to the same deal, separate earned revenue from collected cash, and subtract attributed costs before deciding which work made money.

By SIGNLD Editorial · · 9 min read · Decision Intelligence
Connected customer, deal, invoice, and payment records supporting a deal profitability CRM and accounting comparison.

In this article

Why can't one system answer this?

A closed deal tells you what a customer agreed to buy, not what the company earned after delivering it. HubSpot holds the deal amount, close date, customer relationship, and sales owner. QuickBooks holds invoices, credits, payments, and accounting records. Delivery records hold the hours and expenses that made the work happen.

The CRM's report answers whether a salesperson booked the contract. The accounting report answers what was billed or collected within its chosen period. Neither report necessarily assigns an employee's recorded time to the exact deal that required it. A customer-level total also hides differences between separate projects for that customer.

Deal profitability across CRM and accounting starts with those distinctions. A large booking might contain several delivery periods, while its first invoice covers only a deposit. Treating either figure as the complete revenue makes the resulting margin misleading. Comparing the booking against expenses from a different period makes that problem worse.

You need an agreed revenue basis and a defined cost boundary before comparing deals. For the customer and invoice relationship, see the QuickBooks and HubSpot pairing. For other combinations, browse the integration examples.

How do people answer it today?

The usual starting point is an export of closed deals from the CRM. A finance colleague then exports invoices and payments from accounting for approximately the same dates. An operations colleague supplies project hours, contractor charges, and any reimbursable expenses from delivery records.

Someone builds a matching column using customer names, email domains, or an internal project label. They correct obvious spelling differences and combine renamed accounts. Then they search for invoices without clear deal references and hours logged against a general customer rather than a project.

Next comes the calculation: select the revenue figure, allocate costs, and subtract them. The calculation itself is straightforward once each record belongs to the right deal. The difficult part is explaining the records that were excluded, duplicated, or assigned through judgment rather than an identifier.

A repeatable manual review needs these checks:

  • Confirm the reporting period and the revenue basis before exporting either report.
  • Preserve customer identifiers, deal identifiers, invoice references, and project references alongside display names.
  • Keep invoice lines and payment applications separate so partial payments do not multiply revenue.
  • Record how delivery hours and payroll costs were attributed to each project.
  • Put uncertain matches into a review queue rather than forcing a customer-name match.
  • Save source references and exclusion reasons beside the final calculation.

By the time finance finishes matching, a salesperson may have amended the booking or accounting may have posted a credit. The spreadsheet still reflects the earlier exports. Unless someone preserves the matching decisions, the next reviewer repeats the same detective work without knowing why last month's figures differed.

What does the answer look like when the systems are connected?

Example: an illustrative agency with an illustrative 40-person team uses HubSpot, QuickBooks, generic time tracking, and payroll records. Its owner asks, "Which completed deals earned money after delivery costs, and which still have unpaid invoices?" The question deliberately separates profitability from cash collection.

The connected view reads HubSpot deals and customer records, QuickBooks invoice lines and payment records, and project-level delivery hours. Payroll records supply the agreed labor-cost basis. Matching identifies the customer first, then the specific project or contract behind each deal. Uncertain project assignments remain visible for review.

Measure Illustrative project Cedar Illustrative project Birch
CRM booking Illustrative 100 revenue units Illustrative 100 revenue units
Revenue under the agreed accounting basis Illustrative 90 revenue units Illustrative 90 revenue units
Collected cash Illustrative 70 revenue units Illustrative 90 revenue units
Attributed delivery cost Illustrative 60 revenue units Illustrative 100 revenue units
Contribution before shared overhead Illustrative 30 revenue units Illustrative negative 10 revenue units

The illustrative figures show why a booking total cannot answer the owner's question. Cedar has positive contribution but an unpaid balance. Birch has collected its recorded revenue but consumed more delivery cost than that revenue covered.

The Decision Brief names the revenue basis, the project-matching rule, and the cost categories included. It cites the system, table, and row behind the numbers. It also separates confirmed matches from delivery records that still need an owner to identify the correct project.

The owner's next actions differ by finding. Finance reviews Cedar's outstanding balance and payment status. Operations reviews Birch's extra delivery work against the contracted scope. Neither action requires inventing a revenue number to reconcile the CRM report with accounting.

Which costs belong to a deal?

Start with costs directly attributable to fulfilling the contract. Recorded employee hours, contractor charges, materials, and deal-specific travel usually have a clearer connection than company-wide overhead.

Labor requires both time and an agreed cost rate. A time entry says how long delivery took; payroll contributes the relevant employee-cost basis. Decide whether that basis includes employer charges and other employment costs. Keep that choice consistent across the deals being compared rather than changing it when a margin looks uncomfortable.

Distinguish direct contribution from profit after shared overhead. A deal might cover its delivery cost without covering an allocated share of rent or administration. Both measures have uses, but they answer different questions. Label the chosen measure and show the excluded categories rather than presenting a single unexplained margin.

Missing time is not free time. If project hours were recorded under a general customer, mark the attribution as incomplete. The owner can then decide whether a comparison is ready to use.

How do you distinguish profit from collected cash?

A profitable contract still creates a cash problem if invoices remain unpaid. An upfront payment might improve cash while the business still owes substantial delivery work. Keep booking, billing, earned revenue, and collected cash as separate measures with their own dates. Do not collapse them into one column labeled revenue.

For unbilled work, inspect the contract and the billing milestone before describing a leak. Some completed sales legitimately await delivery or customer acceptance before an invoice is due. The closed deals never invoiced review shows how to separate those cases from missed billing.

When totals disagree, compare the cutoffs and credit treatment before questioning either system. The CRM and accounting revenue reconciliation explains how deal amounts and invoice records drift. The pipeline cash forecast adds payment terms and historical collection behavior to the timing question.

What should you do with unprofitable deal types?

Group completed deals by a concrete delivery characteristic: service package, contract scope, customer segment, or sales owner. Compare their cost composition under the same revenue and cost definitions. Avoid blaming a salesperson for expensive delivery before checking whether the contract included work that was never priced.

A delivery overrun suggests a different intervention from an invoice discount. The first might require tighter scope approval or a changed staffing mix. The second might require a pricing review. A credit issued after customer dissatisfaction deserves its own explanation, not an automatic label that the original sale was poorly priced.

Lead source also belongs in the review when acquisition brings expensive customers. The lead-source-to-paid-revenue review follows that relationship without confusing leads with collections. The commission and unpaid-invoice review examines booking-based compensation fairly, keeping the compensation policy separate from the exposure measurement.

Choose an action owner and keep the Decision Topic open for the next comparable deal. Review whether revised scope, staffing, or pricing changed the recorded outcome.

How does SIGNLD answer it?

SIGNLD supports HubSpot and QuickBooks through read-only connections. The Knowledge Graph builds automatically from connected sources, with no data engineering required. It matches the same customer, deal, and invoice across systems while keeping the relevant revenue definitions distinct. Delivery-cost evidence belongs in the answer when the connected records provide it.

Open a Topic with the profitability question and the reporting period. The answer returns as a Decision Brief citing the system, table, and row behind each number. Review uncertain matches and excluded costs before acting. Your data stays yours: read-only connections, a private LLM powered by AWS Bedrock on a single-tenant instance, and we never train on it.

Key takeaways

  • Deal amounts, invoiced revenue, collected cash, and delivery costs measure different parts of the same sale.
  • Customer matching is not enough when one customer has several projects or contracts.
  • Deal profitability needs an explicit cost rule and a reporting period before any comparison is useful.
  • A Decision Brief should distinguish unprofitable work from profitable work whose invoices remain unpaid.

FAQ

Is a closed deal the same as a profitable deal?

A closed deal records a sales commitment, while a profitable deal earns more than its attributed costs under a defined reporting basis. HubSpot supplies the booking; QuickBooks supplies invoices and payments. Delivery time and payroll records supply labor evidence. Match those records to the specific deal before interpreting its commercial result.

Should deal profitability use invoices or payments?

Deal profitability needs an agreed revenue basis, while cash exposure needs payment records. Invoices describe billed amounts, and payments describe collections against those amounts. Neither automatically represents earned revenue for every contract. Keep each measure separate, label its period, and compare delivery costs with the revenue basis finance has approved for that review.

What if several deals belong to the same customer?

Several deals require matching below the customer level because the same account may have unrelated projects and contracts. Use deal references, project identifiers, invoice references, and the recorded delivery relationship. A customer-name match alone risks allocating all costs to the wrong sale. Keep uncertain assignments visible until the relevant project owner resolves them.

Does connecting records change the source systems?

SIGNLD reads connected records through read-only connections rather than changing HubSpot deals or QuickBooks invoices. The Knowledge Graph matches their customer and transaction relationships for the question. A Decision Brief presents the resulting figures with source citations. Changes to billing, sales records, or project allocation remain actions for the responsible team in its existing systems.

Related reading

Try SIGNLD free

Try SIGNLD free and ask which completed deals covered their recorded delivery costs. Start with the revenue basis and source records your finance team already uses. Browse all articles.