#cristian_subscription-invoice-items-breakdown

1 messages · Page 1 of 1 (latest)

pulsar knollBOT
#

đź‘‹ Welcome to your new thread!

⏲️ We'll be here soon! Typically we respond in a few minutes, but sometimes we might take a bit longer if the server is busy or if you have a particularly tricky question.

⏱️ We close idle threads, which makes them read-only. Once a thread is closed it won't be reopened, but you can always start a new thread if you have another question.

đź”— This thread will always be available, even after it's closed. You can find it again using Discord's search, or you can save this link: https://discord.com/channels/841573134531821608/1334553265689333823

đź“ť Have more to share? Add more details, code, screenshots, videos, etc. below.

distant delta
#

We have a subscription-based service where customers can subscribe to one or more products. Each product can be applied to multiple entities, and we need to list these entities separately on the invoice.

Currently, when we generate an invoice, the products are shown as single line items with the total quantity of entities attached to that product, like this:
Product A ____ 30 x US$500
Product B ____ 50 x US$100

We can add a description, but it is character limited, and it wouldn’t fit all the entities per product

However, what we need is the ability to break down the invoice so that each entity is listed separately under each product, with a unique line item for each entity. Ideally, the invoice should look something like this:
Product A - Entity 1 _______ 1 x US$500
Product A - Entity 2 _______ 1 x US$500
...
Product A - Entity 30 ______ 1 x US$500
Product B - Entity 1 _______ 1 x US$100
Product B - Entity 2 _______ 1 x US$100
...
Product B - Entity 50 ______ 1 x US$100
We attempted to achieve this by using the send_invoice collection method, which keeps the invoice in draft state to allow us to manually adjust the line items. However, this approach doesn’t work well for recurring pricing, as it requires one-time payments for line item adjustments.

We understand that some users, like Temporal (which also uses Stripe), are able to achieve a similar result using metered usage, where each instance is treated as a separate line item. However, our usage is not metered, so this solution doesn’t apply to us.

We would like to know if there is a way to achieve a separate line item for each entity under a given product for recurring charges. Our goal is to allow our customers to clearly see and consolidate charges per entity.

#

It would also be acceptable if the invoice could look something like this:
Product A _________ 30 x US$500
Entity 1
Entity 2
...
Entity 30
Product B _________ 50 x US$100
Entity 1
Entity 2
...
Entity 50
We have not found a way to accomplish this using the API. Could you please advise if there’s a recommended approach or any existing Stripe features we could use to achieve this level of granularity on our invoices?

ember orchid
#

Thanks for explaining, i think I have a path for you

#

Do these items corresponding to separate subscription items?

distant delta
#

No, we primarily offer two products, and each entity can choose to subscribe to either one or both of them. To reflect this, we adjust the quantity in the subscription, which results in a single line item per product. However, our customers need to be able to see which specific entities are linked to each product.

When we create a subscription, we have one or two subscription items, each with a price and quantity (representing the number of entities).

ember orchid
#

You can't really split this up then if its a single item & quantity, there's no affordance for that

#

The only option for that scenario would be breaking it down in the memo details, but there would be limited space for that for long breakdowns

distant delta
#

Does that mean we would need to have a product per entity?

ember orchid
#

Using metadata to mark the entity, even if the product was the same

#

No, but you might need a price per entity since i don't think you can include two subscription items with the same price object

distant delta
distant delta
ember orchid
#

That's what rendering templates help with. You can put the entity in metadata and have the items grouped by that.

distant delta
#

limited to 50 keys

ember orchid
#

Can you elaborate on why thats an issue?

#

Why would you need more than 50 here?

distant delta
#

in theory a customer can have dozens of entities across products and each entity name could be really long (40 characters+)

ember orchid
#

That would be the value though, not the key

#

the key would be the same on all items, something like metadata[invoice_entity_name]="Entity ABC123"

#

then the other would be
metadata[invoice_entity_name]="Entity XYZ456"

distant delta
#

metadata has a limit of key names up to 40 characters long and values up to 500 characters

ember orchid
#

yes

#

is one of those an issue for you?

distant delta
#

if we do an entry per entity we are limited to 50 entities metadata[entity_a] = "product A, product B"
if we do an entry per product we are limited to 500 characters to all entity names. metadata[product_a] = "Entity A, Entity B, Entity C..."

#

Oh, wait, you mean like a metadata per line

#

So we would have a product, and for each product a number of prices, and each price has the entity name in the metadata, and from the invoice rendering template we are able to fetch the entity name from the metadata and render it in the invoice programatically, is that it?

ember orchid
#

I would say the entity on the subscription item, but price works too if per entity

#

You don't "look it up" per se, you configure the tempate grouping logic to extract from that location

#

The key would likely be the same for all items

#

With the value being the entity to group by

#

but you should test this out to see if it gets you appropriate results

distant delta
#

So when creating a subscription, when we specify the items, we would have one line per entity, using the same price (as the cost is the same), and each line would have the entity name in the metadata?

Items: [
    {
        price: "product_a_price_one",
        quantity: 1,
        metadata: {
            entity_name: "Entity A",
        },
     }
    {
        price: "product_a_price_one",
        quantity: 1,
        metadata: {
            entity_name: "Entity B",
        },
     }
    {
        price: "product_a_price_one",
        quantity: 1,
        metadata: {
            entity_name: "Entity C",
        },
     }
]
#

and since all prices belong to the same product we wouldnt hit the 20 products per subscription limit, right?

ember orchid
#

Hmm yes if there's that much of a breakdown

#

Honestly you should consider making this separate subscriptions in that case, one per entity

#

in which case you dont even need to separate prices, you can use the same ones for all of them

#

At the core, you want to provide more detail about the invoice line items that we support

#

An alternative here would be invoicing the simplified total, then separately providing the customer with a breakdown of each item per entity

distant delta
#

We already have built a complex subscription system. Each customer can have multiple different payment methods, and link a set of entities to it, so we have a subscription per payment method, but still need to split the entities per product

ember orchid
#

But our invoices dont support this

distant delta
#

we considered doing a subscription per entity, but if they all used the same payment method the customer would be bombarded with hundreds of invoices

distant delta
pulsar knollBOT
distant delta
#

Other than this price per entity approach, can you think of any other solution we could try in Stripe?

ember orchid
#

Nothing that we support today.

#

how many entities x products would you expect to invoice for?

ember orchid
distant delta
ember orchid
#

For context, I am trying to understand your use case here and what possible paths we choose could support you in future to file the feedback most effectively.

#

I'm a bit confused, why would this be per payment method?

#

What defines the contours of a "customer" that includes a group of "entities"?

distant delta
#

Our customers manage a set of entities (such as companies or organizations), and each entity can have multiple foreign registrations across different states, along with its own payment method.

We offer the flexibility to create a subscription for each entity (based on its individual payment method), or for a group of entities sharing the same payment method, such as in the case of venture capital management funds.

To facilitate better reconciliation, our customers need to clearly see which entity incurred which charges. However, when an invoice only lists the quantity and total amount, it becomes difficult for them to identify which specific entities were charged.

#

So, we can have three different scenarios for different customers:

One subscription for all entities – All entities are grouped under the same payment method.
One subscription per entity – Each entity has its own payment method and subscription.
Multiple subscriptions per set of entities – For example, three payment methods, each handling 10 different entities.
In all of these cases, it’s important for our customers to clearly identify which entity is associated with which charge on their invoice.
The current invoice format, which lists only the total quantity and amount, makes it challenging to reconcile charges at the entity level. Ideally, we'd like to have the option to list each entity separately on the invoice, so that the customer can easily track their usage and payments.

#

We have all that sorted out already, we only need to solve this Invoice issue

#

In theory, we could have a customer with 300 entities under the same subscription and payment method. However, the current limitations in Stripe prevent us from displaying all the entity names on the invoice

ember orchid
#

I honestly don't think we have a good solution for these requirements right now, even within beta/preview/future features I'm aware of.

#

As far as I can tell, you'll be better served generating your own detailed invoices to this particular spec

distant delta
ember orchid
#

You could still use Subscriptions for the consolidated final payment for the aggregated price/product quantity, and send your own invoice PDF for the breakdown

distant delta
#

I will pass along these informations to the team

#

Thank you Synthrider, I really appreciate your time and assistance in helping me find a solution

ember orchid
#

My pleasure, an interesting challenge and I hope we can offer more flexible options in future!

distant delta
#

If we could specify a description under the invoice line per quantity, it would solve everything

ember orchid
#

I'm going to try to capture your request to share this feedback. If you want to share your account ID and/or email addres (via DM if you prefer) I can attach that and our product team would be able to reach out later if we have something to offer.

#

I sent you a friend request if you would like to DM those details

distant delta
#

It makes sense if you think of it, say you have an invoice for 20 iPhones, you have:
iPhone N __________ 20 x US$750

it would make sense to be able to list the serial numbers in the invoice

iPhone N __________ 20 x US$750
    Serial: AAAAAAAAAA
    Serial: BBBBBBBBBB
    Serial: CCCCCCCCCC
ember orchid
#

Yep, some kind of sub-item details or breakdown is the direction i was going to take this

#

We don't have anything like that now, but that's what i think would be the solution here.

#

I need to step away, but I'll check my messages later if you want to send that.

distant delta
#

Sure thing! Thank you again 🙂