Ian Landsman is Starting From Scratch, March 2, 2007:
What They Never Told You About Handling B2B Transactions
If you're in the market for a powerful and user friendly Help Desk solution, please take a look at my company's flagship product HelpSpot.
When I started UserScape I had no idea how to handle transactions in a B2B software company. For all that’s written about starting a software company and how to run a software company, there’s very little on what types of transactions you’ll need to support and how you should go about doing them. If you think you’re just going to put up a PayPal button and call it a day you are very very wrong!
Your customers have a variety of methods they like to pay with and so you’ll need to support those methods of payment. It’s also important to understand billing options and how they relate to payment options.
We currently have 3 billing options for HelpSpot. Credit Card (instant billing essentially), Purchase Orders with invoicing, and Invoices. Acceptable payment for these billing options are credit card (with some exceptions we’ll see below), check, bank transfer and sometimes PayPal.
The most common form of billing and payment is of course to use a credit card. Obviously you need to accept credit cards and you likely already knew that, but here’s something to keep in mind. There’s no reason you have to allow all purchases to use a credit card. Specifically, we currently only allow charges up to $2,000. This is high enough to cover the very popular 10 pack license option ($1,699), but low enough to keep our costs down. Credit card transactions can be very expensive at these higher price points. For example, most charges cost 3-4% of the transaction if you’re directly using a gateway like Authorize.net. Of course if you’re going through a third party processor like esellerate and the ilk, then it can be 10-15%. Even at 3-4% though this really ads up. A $2,000 charge costs me $80 or so. Compare that to the cost of processing a check which is $0 or doing a bank transfer which is generally $15. That’s a significant savings and can really add up.
At first I was concerned that the limit would be a negative. In fact the limit was actually impossed upon me by my merchant account bank. As a new company they capped any single transaction to $2,000. I tried to fight this because I was worried that customers wouldn’t buy if they needed to charge more, but they wouldn’t budge since I had no history. In practice it turns out that this is really a non-issue. Most companies spending more than $2,000 will want to use your invoicing options or at least have no problem using invoicing since it’s common practice. In fact I’ve never even bothered going back to my merchant bank to get the limit upped. In the one and a half years of selling HelpSpot only once has a customers wanted to pay by credit card for an amount over $2,000 and I went ahead and processed it as two transactions manually.
Now our other two billing options are somewhat intermingled. Purchase orders and invoices. Boy I wish I knew more about purchase orders before I started UserScape. Here’s the skinny on them. A purchase order is basically a contract, once you accept a purchase order from an organization there’s a contract formed that basically says they agree to pay you X and you agree to deliver Y immediately pursuant to the payment terms outlined in the purchase order. So when you receive a purchase order you’re are obligated to immediately ship the product (generally speaking) or in this case ship the license file. You then invoice the company for payment. The terms we use are Net 30 which means they must pay the full amount within 30 days. It’s common in many industries to actual provide discounts for early payments, but I haven’t had any collection issues so there’s been no need for this incentive.
Since there’s almost nothing out there on this, here’s the exact details of how the process usually works.
- The customer decides to purchase HelpSpot and goes to their manager to receive approval for the purchase order
- Once they have a purchase order they go to the UserScape store
- In the store they select the invoice option and fill in the optional PO number off their PO
- After completing the store form they also fax us the physical PO so we have a copy
- Once we receive the PO fax the purchase is OK’d in our system and it’s marked as being a PO purchase
- The order moves to a receivables queue and the license key file is sent since we’ve accepted the PO and are obligated to ship it
- We send out the invoice, usually via a PDF attached to an email though we’ll also physically mail it if asked
- Receive payment via check or bank transfer
It seems like a lot of steps, but it’s really not bad. Now it’s also possible for customers to be invoiced without a PO. Since there’s not the same contractual obligation there and in my eyes not the same level of commitment no license is shipped until payment is received. I will often extend trials as needed though so that the customer doesn’t have to do without HelpSpot while waiting for us to receive payment. In this case the process goes as follows.
- The customer completes the UserScape store forms indicating the invoice option
- We receive the order and send out the invoice, moving the order to the receivables queue, but no shipping the license
- Receive payment via check or bank transfer
- Send license once payment clears
That’s pretty much billing. It sounds a bit intimidating, but it’s really very straight forward. One big tip is to make sure your back end systems are expecting these type of transactions. If your CRM and license systems are setup to expect instant payments via credit card and you start doing invoices you’ll be in a mess trying to figure out what’s still outstanding and where everyone is at in the payment process.
For payment types, we’ve already covered credit cards so let’s jump into checks. I love checks! When I started UserScape I never thought I’d say that, I despised the idea of dealing with checks. I wanted to be completely virtual. Checks though have a unique quality that no other payment type has. They generally cost nothing to process. No middle men, nobody taking a cut, pure profit. When you’re looking at transaction fees potentially in the hundreds of dollars a trip to the bank now and then doesn’t seem so bad.
Another thing I knew nothing about when I started was bank transfers. Accepting bank transfers is really critical, especially if you’re selling to international customers and of course if you’re selling online you will be. Most international customers (outside the US) don’t like to pay with checks, it’s problematic. So they prefer to pay via bank transfers. In fact every international sale of HelpSpot, currently 25-30% of our business, has been paid by either credit card or bank transfer.
To do bank transfers you’ll need to have an account at a bank (duh). But make sure it’s an actual bank and not a credit union. The main UserScape account is at a credit union where I’ve done business for years. Unfortunately, my credit union (and I think most credit unions) didn’t have a SWIFT code. This code is often required for international transfers so if your bank doesn’t have one then a transfer can’t be done. To get around this I ended up setting up an account just for transfers at HSBC and that’s worked out very well. To do a transfer all you’ll need to send your customers is this basic information:
Bank: HSBC
Bank Address:
1 LaGrange Avenue
Poughkeepsie, NY 12603
United States of America
SWIFT: MRMDUS33
Routing: XXXXXXXX
Account: XXXXXXXX
Account Name: UserScape
That’s it and in a few days bingo bango money is in your account. The fee is usually $15 which isn’t too bad and will generally be less expensive than credit card fees.
The final way we accept payment is via PayPal. This actually isn’t a published option, but there have been 2 customers who have wanted to pay via PayPal so we have the account. Again I believe both were international and it was just easier to do it via PayPal for them.
This setup has worked out really well for the past year and a half. Customers have the flexibility to send payments in the way that works best for them and providing all the options doesn’t really add much to the work load for us. In fact the cost savings and increased sales more than makes up for the extra work.
Hopefully this post has cleared up a few things for aspiring ISV’s out there looking to enter the B2B space. I unfortunately had to figure out most of this through trial and error, so maybe it can save some of you a bit of time and money. If you’re an established ISV and have other tips and tricks please post them in the comments, there’s always more to learn.
Discussion
> So when you receive a purchase order you’re are obligated to
> immediately ship the product
I'm not sure this is correct. Contract law is basically offer and acceptance. At the point that you have received a purchase order, the offer is made. The contract doesn't become valid until you have invoiced them. However, if you send them a quote for the license and terms, then that may constitute the offer and the PO becomes the acceptance.
I really need to find this out for my own satisfaction.
Several other points to add that I've learned recently:
- Having a fax machine comes in handy. Some large companies will place a PO and just have you sign it and fax it back, essentially making the PO the Invoice as well. Fax machines are reasonably cheap and can serve dual duty as 20ppm networked, B&W printers, so they're not a total waste.
- Make sure you have a W-9 ready to send out. The larger the company, the more likely they will require one. If you are a vendor operating outside the U.S., a W-8 is the equivalent.
- State your terms clearly on the Quote (if you do one) and Invoice. The terms are typically Net 30 with a 10% late fee for any payments after 30 days. Also, state the monthly interest rate for late payments, and the terms under which the license agreement becomes invalid (e.g., late payment past 90 days).
- Leaving nothing to chance, I also restate the form of delivery (electronic) and the maintenance agreement (in my case, a single point of contact within the organization and what the upgrade terms are).
THIS is why we need a BoS wiki. I was sweating it when I had one day to figure this all out.
-- Nick
Created by Nick Hebb on 03.02.2007 7:58 pm
Great comment Nick. My understanding was that accepting the PO was the contract and not actually sending the invoice, though in practice the invoice is the obvious proof of acceptance.
I second the W9, just keep a digital version on file signed and ready to go.
I also second the fax machine. I actually use a jfax account right now (digital send/receive) and it's really not good. I need to get a real fax machine at some point. jfax is OK for receiving, but sending stinks.
I actually purchased a domain for doing an ISV wiki, but it sounded like others were working on one already. If that's not the case I'm happy to host one on that domain.
Created by Ian on 03.02.2007 8:07 pm
Thanks for the post, Ian - very, very useful stuff. These are the kinds of things you're expected to know about when you're in business for yourself...
Created by Jim Martin on 03.02.2007 8:19 pm
Thanks, very informative post.
Created by QS on 03.02.2007 8:22 pm
I'll follow up on offer/acceptance issue next week. I have to meet with my accountant, and he should be able to answer this question (if not, I probably need to find a different accountant.)
How do you digitally sign a W9 or PO? Do you use a scanned image of your signature?
> I actually purchased a domain for doing an ISV wiki
As the Kuwaiti's say, we're two butts in one underwear on that one*. I registered myisv.com but never got around to creating the wiki. Then I turned it into a blog and never got around to posting on it. I'm thinking about opening it up to all posters who want to do software reviews, site reviews, topical content, etc. - but right now that's on the back burner.
(* i.e., in agreement - not the other thing you might be thinking.)
Created by Nick Hebb on 03.02.2007 8:30 pm
Sounds like we need bigger underwear 
I have a scanned version of the w9 all filed out which I email as needed.
Created by Ian on 03.02.2007 8:32 pm
This is an excellent post Ian, thank you for sharing your experience with handling payments.
Created by Scott Carpenter on 03.04.2007 3:43 am
Thanks Scott, great to hear you've found it helpful.
Created by Ian on 03.04.2007 5:28 am
Good article. Just saved it to my delicious.
I have been having transactions wire transfered to my HSBC account from US to Malaysia a few times. All I supplied to the other person are:
- Bank Name
- Branch Address
- Swift Code
- Account Number
- Account Name
Do you think "Routing Code" is really necessary?
Created by Say Joe on 03.04.2007 10:32 am
I'm not sure. I do know that at least one customer in the UK needed it, but that may be something specific to their bank. I just include it in case they need it so we don't have to go back and forth.
Created by Ian on 03.04.2007 11:15 am
Useful post Ian. I think a lot of people don't understand these sort of basics (I didn't a couple of years ago), but are embarassed to admit it - especially to their customers.
I believe the full process is usually:
-quote (from you)
-purchase order (from them)
-invoice (from you)
-deliverable (from you)
-payment (from them)
Often with a few late payment reminders from you!
I made an international payment last week using swift. HSBC charged me £21 (about $40). I also get charged £0.60 (about $1) for every check(cheque) I cash. I guess we are used to be reamed by our banks here in the UK.
Created by andybrice on 03.04.2007 7:32 pm
Ouch - those are some pretty high fees, Andy. In the US we may have customer service from banks ranging from apathy to downright hostility, but at least the competition has driven most of the fees down...
Created by Jim Martin on 03.04.2007 10:19 pm
>customer service from banks ranging from apathy to downright hostility
Ours is mostly outsourced to India. If nothing else they are generally very polite. ;0)
Created by Andy Brice on 03.07.2007 6:53 am
Thanks for the information. I'm embarrassed to admit that I didn't know that the contract was made once the purchase order had been placed (or after the invoice was made). For some reason I thought it was after payment - I've been shipping a 45 day temp licence key immediately on placement of a PO, and then sending a permanent licence key on payment. Oops!
Created by Martin Bromley on 03.07.2007 3:34 pm
Hey, great to see it's already been useful! Yep, once you accept the PO that's the contract. I guess "acceptance" has some wiggle room, but it's somewhere between when you receive it and when you send an invoice.
Created by Ian on 03.07.2007 3:37 pm