CSA features: understanding how CSA work and the gap with current standing orders feature

[MyriamBoure]

Continuing discussion from CSA subscription contracts management feature: oportunity in France with the CSA network and Subscriptions: Next steps for the beta

A- Some basic legal / accounting principles

It is not possible to ask a payment without an invoice. This is an international accounting principle. AND the rule is that you cannot issue an invoice before the property of the products concerned has been transferred.
There are some exceptions, especially, it is possible to sell something that you gonna deliver in a long time, and in the terms of sale (= sales contract), you can precise that “30% has to be paid at order time” for instance. This means you can issue a “deposit invoice” and ask the customer to partially pay before the product has been delivered.

Another important rule : legally, you cannot sell anything without a sales contract (= terms of sale). Have you bought something on Amazon ? You always have a checkbox at checkout “I have read and accept terms of sales”. A sale is a commercial transaction ruled by a contract.
I guess most marketplaces have in the marketplace “terms and conditions” the terms of sales, that are the same for all sellers. THIS IS NOT OUR CASE. We have nothing in our terms and conditions, and I think that logic would be hard with our subsidiarity principle, every hub probably should have their own terms of sales that their customer need to “validate” at checkout.

You can translate this French page that explains pretty clearly that obligation.

B- Enabling customers to plan automatic orders vs pre-selling 30 baskets vs selling a subscription

We can distinguish 3 cases:
1- A hub wants to enable customers to automate orders. A customer plan in advance a future order, but at the moment the planning is done (standing order is set up) there is no transaction, no sale happened. There is no commitment, a customer can pause or stop the planned order. The sale and invoicing happen at each OC.
2- A hub wants to pre-sell a set of baskets. The hub can offer customers to buy in advance baskets they gonna receive in the coming weeks. In that case what is bought is a specific product (ex: a 3kg seasonal basket). Legally, it is normally not possible to invoice something you have sold but not delivered. You can issue “deposit invoices” to get some prepayments. So it is legally possible to capture a “sale” long in advance before the products are delivered, and ask “deposit” through “deposit invoice”, but the remaining can only be invoiced once the products are delivered. So the transaction is complete when all the basket pre-sold are delivered. If a basket can’t be delivered, or is 1kg instead of 3kg, the customer can asked to be reimbursed as the “sales contract” is not honored.
3- A hub wants to sell a subscription for a weekly seasonal basket. The hub needs to specify what product the suibscription is for (ex: seasonal basket medium, estimated 5kg) BUT can specify in the sales contract that if there is no harvest, the basket can be empty. The transaction happens and is complete at the sale of the subscription. What is sold here is not a bunch of products, but a subscription. The subscription IS a product in itself. It can be invoiced and money can be asked straight away, just like when you subscribe to a magazine. If the sales contract attached to the subscription is not honored (terms not respected by seller) the customer can sue the seller.

C- The “CSA contract”

As explained above, the “terms of sale” = sales contract is something that any seller need their customer to accept. In the case of CSA in France, they have formalized in a pretty “heavy” way that contract as they really wanted the CSA members to understand what they were committing to. But it would be possible, and they would be open to that, to “transform” their contract into some form of “sales contract / terms of sale” that specify what the customer commit to when buying a CSA subscription.

For example a CSA would include in their ToS:

• That the size and content of basket can vary depending on the producer harvest, and that if no harvest, the basket can be empty.
• That weeks of delivery are planned in advance, and if customer can’t collect her basket, she loses it. Some CSA can propose to postpone under specific conditions.
• The total amount is payable at the moment the subscription is purchased. Some CSA can offer payment facilities/schedules.
• etc.

D- Step by step operation and accounting regarding the sale of a subscription

THIS IS IMPORTANT TO UNDERSTAND OR WE WILL BUILD THE FEATURE WRONGLY

1- A subscription is sold.
411 client (D) (for the total amount of the subscription for the period)
707 goods sales (C) (for the total amount of the subscription for the period)
As the transaction happens, the customer receives an invoice for the whole subscription amount. The seller might offer some payment facility, like “pay now 40% and you can pay 30% next months and 30% the months after”. So after invoicing is done, payment can happen later. But the “share” has been bought by the customer, the commitment is sealed through the sales contract (see above).

2- As the turnover for all the basket sold in advance through the subscription has been recognized before the product ownership has been transferred, a corrective operation is registered in accounting to say that this turnover are “deffered income” = income perceived before the delivery of the product sold actually happened.
707 goods sales (D) (for the total amount of the subscription for the period)
487 Deffered income (C) (for the total amount of the subscription for the period)

3- At each basket delivery, a new accounting line is recorded to recognize the turnover corresponding to the product actually delivered, which has already been invoiced through the subscription sales
487 Deffered income (D) (for the amount of the weekly basket)
707 goods sales (C) (for the amount of the weekly basket)

No invoicing happens at the delivery stage as the products delivered have already invoiced ! So the delivery (proved by a delivery note) triggers a turnover recognition, but not a billing.

When the last delivery promised in the contract is done, and payment is all done, the contract has been fully executed.

4- When a total/partial payment from the customer happens, it cleans the customer debt towards the seller
512 Bank (D)
411 client (C)
This depends on the payment plan offered to the customer when they buy the subscription.

E- What are the needs/problems not yet satisfied

That could be different stories of a “CSA can sell subscriptions” icebox. Or maybe we need to split in multiple needs and handle them one by one, but some will need to be released together as are dependent on each other. Not sure what would be the order, but the very first icebox/need for me would be to “a subscription a can be sold, purchased, billed”.

• Today it is not possible to buy a subscription and be invoiced for it, and pay for it.
  • We need to create some new type of product that can be purchased that is a subscription for a given product for a certain number of weeks / delivery schedule (not a composed product). When it is bought, it is billed. > Make a subscription a PRODUCT that can be bought and invoiced for.
  • Hub needs flexibility on the rules attached to that subscription (ex: customer can postpone a basket or not, etc.) Those rules will determine what a customer can/can’t do when editing a subscription / postponing a delivery, etc.
  • It is not possible to have products in an OC delivered but not billed, which we need to make possible as products that are part of a subscription have already been bought and invoiced. For instance, a product attached to a sold subscription can be 'tagged" as not billable and not appear in OC invoice.
  • Products already bought through a subscription can’t be cancelled, removed from basket. Maybe they shouldn’t even appear in the basket as they have already been sold, so it can be confusing if you see them again in your OC basket…
  • It is not possible to propose payment schedules attached to payment methods = payment facilities like “buy now and pay given interest-free payment plan” (v2, payment can be handled out of OFN in v1)
  • We need to implement some customer front end to buy a subscription that has been put for sale by a hub (which is different from a customer front end to “set up a recurring order” @danielle important to have in mind), and then do the action you can do on that subs (postpone a delivery, etc.)
• It is not possible to set up (hub) and validate (customer) hub terms of sales.
  • A hub need to be able to upload term of sales
  • At checkout, customer needs to be able to validate them (for CSA they would like more than a checkbox to make sure customer understand what they sign for, but can be in v2)

@Kirsten @tschumilas @luisramos0 @Rachel I summed up all what I shared with you and we discussed last week. @danielle @sstead I know it’s a bit boring but it’s important that you understand all what’s in that post as crucial to plan the future of “subscription” IMO.

[sstead]

Thanks for this post @MyriamBoure, it’s very clear and I now see the distinction between what each model requires and how current subs will fall short. I wonder how many users globally need a true susbcription functionality (your B-3 model), and how many need the current recurring order functionality (B-1, and to an extent B-2)?

[tschumilas]

I think this sums up our conversation. A couple of additions - just for added clarity:

1. In Canada most CSAs sell subscriptions (as you outline above), but then also sell individual ‘add in’ items weekly to that subscription. So, while there would be no billing weekly to the buyer for the subscription, there would still be billing for ‘add in’’ items from a shopfront (ie. extra tomatoes, eggs, …)
2. Many CSAs, in their stated terms, outline their cancellation policy. Its usually a prorated plan - so for ex: Cancel in week 3, refund = xx, cancel after week 8 - no refund… So, of course the hub would write this in their terms - but I’m not sure what would happen for the refund from the accounting perspective, I just mention it in case it matters.
3. Many CSAs here collect donations from subscribers (beyond the price of the subscription) and then use this money to discount a subscription for someone who had difficulty paying. Be nice to put this kind of a feature on our wishlist too.
4. Finally - CSAs here are big communicators with their subscribers/members. At a minimum emails go to members twice a week, plus lots of other communications about events in the community, advocacy… Building community is the CSAs number one priority. And they need to organize their members for these communications (eg. by pick up location, by share size, by payment status…) So unfortunatley, OFN doesn’t enable this high level of customer management and communication with members now. If our intent here is to brainstorm a wishlist of features for CSA, then member management and communications needs to be there. I worry that here in Canada, without this, our platform will not appeal to CSAs anyway (which is why I’m in favour if small hacks to what we have so its useful to 25% of CSAs instead of major work so its useful to 100%)
   .

[lin_d_hop]

Hi all, jumping on this old thread.

I definitely agree that these features are very important.

In terms of contracts and subscriptions, I feel that actually much of this can be handled by Subs1 with some external and surrounding systems that allow CSAs to set up a contract and manage the accounts. Currently in the UK we would encourage users to just set up a google form to do this because a simple google form has all of the features and is much more simple. Once a user fills in the google form the feature fits well with Subs1 - the CSA admin can set up a subscription for the user on OFN if that was useful. Obviously this is not a perfect solution, but the solution is much more relevant to the user than anything OFN currently offers.

Part of the rationale of suggesting this distinction is to keep OFN focused on what we do and what we want to do well. I wonder if it is useful to conceptualise this functionality and a modular piece that integrates with core OFN.

Inside core OFN:

• managing orders, packing sheets, delivery sheets, inventory, payments

Outside core OFN

• contractual agreements, accounting packages.

Once a contractual agreement is set up this integrates with OFN by triggering weekly orders within an order cycle. This is actually what subs1 was designed for.

Can all of the above be handled by setting up a Google Form that includes T&C checkbox, externally handling payment, then using subs1 to handle the rest? I agree that this means OFN does very little, but this is still a service that instance managers can offer to users meaning OFN is still providing value to the users.

[tschumilas]

I agree - OFN already has the core bits that a CSA needs - its all the ‘trimmings’ that we are missing - the agreement, the accounting package, and (I want to make sure we add) communications with members. Farmer-member communication is what makes a CSA different from a food hub or food box program here. OFN tools don’t help much with that relationship right now. So - integrations with mailchimp for example might be the way to go.

[lin_d_hop]

@tschumilas Here is how the UK integrate with Mailchimp

Integrating OFN with Mailchimp (the hacky way)

As many of you know, in the UK we have set up OFN users to integrate with Mailchimp using Zapier. This has been integral to building our business model as it is one of our paid features and most of the users that pay for OFN use this feature. It’s super simple. After the initial set up and first integration, future integrations to Mailchimp for other users take about 2 minutes. How to do it: You need a Zapier account. To get a paid account for free you need to put the Zapier logo somewhere…

[Kirsten]

and possibly the google form could be used to directly create the customer at least via your magical zapping @lin_d_hop?

[lin_d_hop]

With a couple of API endpoints we could use OFN in conjuction with google forms to do all kinds of beautiful magic.

[tschumilas]

I’ve just been thinking about the other post from @danielle framing our global hangout discussion and want to understand something. Right now dev skills are at a premium - and that’s our bottleneck. With this Zapier stuff - is it the same skill set? I understand that API is already in the pipe. So - might we be thinking about a couple of Zap people - in addition to our current dev team - working in parallel? And if so - would they need the same amount of mentoring? For ex - could this be a specific search for a group of global volunteers? I"m trying to think of a way to accomplish some things without adding so much to the dev team.