How your data fits together

Most companies have more than one system that knows about their customers: billing, your own product, perhaps a CRM. Summerbase lets each of them describe the same customer without overwriting the others.

One customer, many sources

A customer exists once in Summerbase, however many sources know about them. Each source has its own id for the customer, called an identity, written as the source’s slug and its id:

stripe:cus_NfJG2nK3
backend:acct_4821

Either one finds the same customer. A custom source links its id to another source’s by listing that id among the customer’s identities.

Each source has its own properties

Anything a source knows about a customer, such as an industry, a plan tier or an account manager, is a property. Properties are kept per source. If Stripe says a customer’s industry is “Fintech” and your backend says “Financial services”, Summerbase keeps both, and reports and filters say which source each one came from.

Three kinds of field

Properties are only part of what Summerbase knows about a customer or subscription. Every field falls into one of three kinds, depending on who may set it:

Kind	Examples	Who sets it
Exclusive	A subscription’s status, dates, amounts and items. A price’s name, archived status and terms	Only the source the subscription or price belongs to
Promoted	A customer’s name, email, country and sign-up date. A plan’s name and archived status	Any source, as a property. Summerbase promotes the value from the highest-ranked source that has one to be the customer’s or plan’s own
Derived	A customer’s status, MRR, and the date they first paid	Summerbase, from everything above

You can change how sources rank on each source’s page, under Edit details. By default, a custom source ranks above Stripe, so what your own system calls a customer wins.

Subscriptions belong to one source

A subscription lives in the source that bills it, and only that source can change it. That keeps the money in one place: two systems can never disagree about what a customer pays.

Other sources can still add properties to a subscription, such as the sales rep who closed it or the channel it came through.

Plans and prices

A price is what a billing source bills: a Stripe price, a Chargebee item price, or a plan in a billing system that has no prices. It belongs to its source, and only that source can rename it, archive it or change its terms: its currency, how often it bills, whether it is fixed, tiered or metered, and its amount per unit. The terms describe your price list. What a customer actually pays is still their subscription item’s own amount, which can differ.

A plan is one thing you sell, such as Pro or Team, and it belongs to your project, not to any source. Every price is on exactly one plan, so monthly and annual Pro are two prices on one plan, and so are Pro in Stripe and Pro in the billing system you used before it. A plan that belonged to one source couldn’t hold all of these, and your revenue by plan would be split across billing intervals, currencies and billing systems.

A plan’s name and archived status are promoted, like a customer’s name. Each source says its own, and the highest-ranked one wins. So renaming a plan in Summerbase beats the product name in Stripe, while a rename in Stripe still reaches a plan nobody has renamed in Summerbase. Stripe sends each of its products as a plan.

A subscription item names a price, never a plan, and revenue by plan is read through the price. So when you move a price to another plan, or merge two plans, every chart by plan changes all the way back through your history.

Nothing is created on the side. A source sends its plans first, then its prices, each naming its plan, and then the subscriptions on them. A subscription that names a price Summerbase doesn’t have is refused as a whole.