Fifteen line items from one sale

I pulled the property list on the Line Item object a few weeks ago, sorted it by the date HubSpot created each property, and a quarter of the object didn't exist on January 1st. Thirty-three of its 134 native properties were built in 2026, more than in any prior year the object has existed. It closed 2025 with 101, so that's 32.7% growth in seven months, with five months of the year still to run.

I want to keep two numbers apart here, because they get run together easily. Thirty-three out of 134 is a share of today's schema, 25%. The 32.7% is growth over what was there at the end of last year. They aren't the same figure and I'll cite them separately. If you set aside the 30 undated properties every CRM object carries, the platform scaffolding like creation timestamps and owner rollups, the share is 32% of the 104 properties that carry a creation date at all. Widen the window to the start of 2025 and 49 of 134, 37%, arrived in the last nineteen months, which is more than the four years before them put together.

Where the build went

Every native property carries the date HubSpot created it. Grouped by year, the object's own history makes the last nineteen months easy to see:

Read the table as a shape rather than a ledger. The 2019 row is a bulk registry seed, all eighteen landing inside a single second, so it tells you when the registry was written rather than how many decisions were made that year. The 2026 figure has no such caveat. Those 33 properties landed across fourteen different days.

Eighteen of the 33 went into one property group, term, which holds billing periods, proration, billing-cycle anchors and milestone billing. Seven went to general line-item information, four to pricing, three to bundling. Narrow one level further and it's sharper than "billing": eighteen of the 33, 55%, carry prorating in the name, and sixteen of those arrived on a single day. This is a prorating build, mostly one batch, and I think it's fair to read it that way rather than as a general programme. Two smaller facts sit beside it. The bundleinformation group didn't exist before 2025 and every one of its six properties has arrived since, and the term group itself is 70% built since the start of 2025.

Set the line item next to the eleven other objects a sale travels through, quote to cash, ranked by the same measure, the share of each object's native schema built in 2026:

The line item's rate is 1.99x the runner-up, which is subscriptions rather than deals. Deals round to the same "12%" as invoices but sit third. Product, the object a line item is nominally copied from, got one new property in the same seven months, and discounts, fees and taxes got none, which I find more telling than the leader: three objects in the revenue chain got nothing while the object underneath all of them got 33.

This covers the twelve objects a sale actually moves through. I didn't measure contacts, companies or tickets, so it isn't a claim about the whole platform, only about where the construction has gone in the chain money travels.

Two dates worth reading on their own

Two of the 2026 properties say something about where this is heading, and I'd rather show them than characterise them.

On 2026-03-16 HubSpot added hs_parent_object_type_id, a field meant to name what kind of parent record a line item belongs to. It's empty on every ordinary deal, quote, order, invoice or payment line item I looked at. Where it's populated at all, on 56 records in a second portal I checked for this series, it holds exactly one value: 0-721, HubSpot's own Contract object, described in its own schema as the single source of truth for committed revenue. What marks those 56 isn't a single creation source, forty came in through the API and sixteen through HubSpot's billing pipeline directly, but all 56 share a lock, hs_locked set true, and a Contract-shaped creation key. So a field landed in March naming a parent type that, so far, only ever means one thing: this line item belongs to the newer contract-based billing model rather than the classic deal-and-quote one.

On 2026-07-28, six days before I first drafted this, HubSpot added hs_milestone_billing_enabled. No knowledge-base article documents it. HubSpot's own product-update forum says milestone billing is "not available … quite yet; however, it is prioritized on the roadmap." The switch shipped ahead of the feature it switches, which is a reasonable way to build and also the clearest sign I have that the object is under construction rather than finished.

Almost none of it is visible by default

Here's the other half of what the schema read shows, and it's the half that matters more for anyone who works in the interface. Nearly every property that would let you see how this build works is marked hidden: true. That means it isn't on a line item's record page, isn't offered in a list filter, and isn't in the report builder's field picker. Working from the UI the way most admins do, you would not know any of the following exist:

• hs_origin_key, the only property tying a deal-side line item to its quote-side twin, the pair HubSpot deliberately creates as two records for the same sale. Piece 3 of this series is about it.
• hs_tier_ranges and hs_tier_prices, the tier tables that price a line item by quantity band. Neither appears on a record page, so a mis-shaped tier table is invisible from the record itself.
• hs_ramp_key, hs_ramp_group_name and hs_ramp_phase_name, the properties that tie several ordinary line items together into one ramped commitment. None of the three appear in HubSpot's own documented steps for configuring ramp pricing.
• hs_unscaled_total_discount, one formula in one hidden property that states the entire discount policy, what wins when a flat discount and a percentage discount are both set, and what happens when neither is.
• hs_parent_object_type_id and hs_milestone_billing_enabled, both above, both hidden.

None of this needs special access. They come back in the same properties-API response that produced the build-rate table. The definitions just carry hidden: true, so nothing in the interface surfaces them unless someone adds them to a view by hand. I understand why: most of these are machinery, and a record page that showed all of them would be worse for most people. The cost is that the machinery runs whether or not you can see it.

What that costs on one sale

Build this much, this fast, on properties nobody sees by default, and it stops being theoretical fairly quickly. I traced one ordinary sale end to end in a portal I work in. One product, one customer, $9,995 a month, six months. Nothing exotic: a deal, a quote, six monthly payments. If you asked most HubSpot admins how many records that sale produces in the Line Item object, I think most would say one, and a few, thinking about the six charges, would say six or seven.

It's fifteen.

One quote copy, one shared deal-and-order record, one subscription copy, six invoice copies, six payment copies. Every one of them carries the full $9,995 in amount, the property that holds a line item's dollar value, and the most natural thing in the world to sum if you're building a report and nobody has told you otherwise.

A 2.5x overstatement on a clean sale, with nobody having typed a wrong number anywhere. Each of the fifteen exists for a reason I'll get to over the next seven pieces, a deletion-safety mechanism, a billing event that needs its own permanent record, and each one is doing exactly what it was built to do. What none of them does is tell you they're the same sale.

There's a sharper version of the same thing on the one property HubSpot did build a guard for. Six of the fifteen, the invoice copies, read hs_mrr = $0.00 on purpose, so that a monthly invoice doesn't get counted as a monthly subscription. That's a real defence against exactly this problem. It covers one property on one side of one hop, though, so if you sum hs_mrr across all fifteen anyway, nine of them, including all six payment-side copies, still carry it fully populated. Nine times $9,995 is $89,955 a month, for a subscription that bills $9,995. A 9x overstatement on the property that has a defence, against 2.5x on the one that doesn't. Piece 6 is where that lives.

Two things to check this week

• Pull your own line-item property list and sort it by creation date. If your portal looks anything like the two I checked, a real share of what's there didn't exist a year ago, and some of it is hidden by default. Add the hidden properties to a view before deciding you know what's on the object.
• Pull a real subscription's line item and look at what it's associated to, a deal, an order, an invoice, a payment. If your report doesn't filter on that association, it's counting copies as if they were separate sales.

None of it is concealed. It's off by default, the same as any property nobody has added to a view yet, and right now this object carries more of those than any other object in the chain and is adding them faster. The next seven pieces walk each of the fifteen records back to where it came from, starting with the first hop: a line item being born from a product, through a link nothing on the platform actually checks.