Just wait until you meet billing's angry roommate: invoicing.
In the US, an invoice is just a weird PDF that you might glance at before sending off to your accounts payable team. But in other countries, especially those that use VAT style taxing systems, an invoice can be a legal document that expresses costs and taxes in a legally prescribed way for accounting purposes. Many countries have prescriptive rules over how you invoice, who can write invoices, when you can invoice, what goes on an invoice, etc. And every country does it differently.
Are you building a service that charges incrementally many times per period? Or even worse, refunds incrementally? You might be sending a truckload of expensive accounting papers to your customer every month, one per transaction. And each of those pages was printed using government prescribed software from oddball vendors you must use or else.
Many years ago I led a billing team at Yahoo! responsible for billing for premium services in European markets.
My team existed for the sole reason that the European business did not trust that the US payment services team understood European needs, and the "invoice is a legal document" thing was one of them. I spent so many meetings repeating to the US team that no, we could not switch to their invoicing as long as a new software release might retroactively change the template used to show already issued invoices (e.g. the registered office might change, or the VAT number).
We didn't have to deal with printed invoices thankfully, but we did ensure we produced each invoice once and stored it, so that the European finance team could sleep at night.
At the time Yahoo! had 8 different payment platforms. Some of those were due to weirdness around acquisitions and Japan (which was a joint venture), but apart from mine I believe two others also existed because of local weirdness that the local businesses decided it was safest not to let Yahoo! US mess with.
At the time I left, after 3 years of that, we'd managed to get agreements to migrate a few bits and pieces to the US after they'd shown the understood requirements for specific features, but it was like pulling teeth.
I'm Anh-Tho, one of a co-founders of Lago, thanks for your comment!
I was the country manager of France for a US Sequoia-backed company before, and I never ever managed to convince HQ to work on EU invoicing, I think they just did not want to open the pandora box you just described!
And even worse - your biggest customers won't even smell your invoice unless you enter it line by line into some ancient SAP system developed 20 years ago, where everything cloud related is classified as telephony except storage space which must be classified as filing cabinets (movable) or your invoice will be (very slowly) rejected.
And if it is rejected you have to enter it all again by hand; editing isn't a feature.
I don't get what you're talking about. Our biggest customer reluctantly agreed to accept preliminary invoices for acceptance over fax instead of signed-for mail, provided that we also ship a paper version with a red stamp promptly.
Wow, haven’t lived this pain fortunately… but totally understand how hard it is to try building a « modern pricing stack » but being forced to create invoices in old softwares like SAP…
This is a property of how VAT works. In the common scenario, the seller is effectively "tax administrator" for the buyer (much like employer pays payroll taxes on behalf of employee), therefore an invoice triggers two independent payables:
1. Seller to taxman
2. Buyer to seller
Neither seller cares how you handle your payments to the taxman, nor taxman cares about customer payments.
The second part regarding credit/debit invoices is again a property of "append-only double-entry bookkeeping". You fix wrong credit/debit entry with reversed debit/credit entry.
To spell that out: if you made a mistake in an invoice or negotiated a new total or an extra item (or had to drop an item) after creating the invoice, you now need to first create a correction invoice cancelling out the invoice you created and then create a new invoice. All three documents must have different numbers. Oh, and invoice numbers must be sequential and continuous.
Many years ago, my dad wrote an accounting system for the company he worked at to automate some of this. He spent ages trying to convince the tax authorities that the database was sufficient, and that there was no point in printing out an extra copy of every invoice and gluing it into a book. The idea is it'd make it harder for you to retroactively manipulate invoices.
They eventually saw the light, but it was a long slog.
In the recent years Germany has started allowing companies to no longer issue print invoices. But you still need to keep a copy of every generated invoice.
Initially "digital invoice" meant that you had to get the invoice cryptographically signed by the same government agency also in charge of literally printing money (or an officially licensed company) and then ideally send it using the now mostly defunct monstrosity that is De-Mail because it made guarantees about end-to-end encrpytion and sender/recipient authentication. Luckily this is now largely irrelevant and most companies just send regular PDFs via e-mail and/or make them available for download.
Yup, it's a nightmare. Invoices needing to be in specific number sequences. Any corrections need to be dealt with by reissuing a special "corrective invoice". Don't even get me started on geocoding for taxes. Urgh. Also, when you've got the invoicing right, you've got to work out how to do the feeds to the accounting systems so that it all posts to the right place.
Yep, fortunately in Europe we can issue credit notes, making our job easier. I do think giving the possibility to send charges information to a webhook is a great way to start: this data can be plugged to any invoicing system (or any tax, payment providers) who are trying to solve those things.
The hardest part for me, when working in that fintech, was to build the whole logic to trigger the invoice, not so much the invoice itself. But this company was a EU company, probably easier to work with invoices
I’ll add that the accounting side can get complicated really quickly. You end up with lots of different scenarios. Earned but unbilled: out of bundle call charges, for example. Billed but unearned: a paid in advance monthly fee, for example - this may need to be recognised as a percentage per day. Etc etc. So much to take into account when feeding to ledgers.
> When someone in sales issues an invoice with a negative amount
I worked briefly with a tax-saas, and to handle refunds I just... did a negative amount. It worked! Except.... I hadn't looked closely. Their API removed the negative. A charge of -$7.92 was just a charge of $7.92. Their docs indicated "we don't accept negative numbers - use a refund transaction instead" but... the API accepted the negative number, then changed it to a positive, and kept running. No error code returned. Really really poor experience, and I hope they've fixed that.
In Italy too. They specifically developed an XML format for that, and each time you issue an invoice you have to (well, with some exceptions, but they are gradually removing all of them) send a copy to the revenue agency, which will forward it to the recipient (and keep a copy).
While it is a bit inconvenient, though, I don't think it is a bad idea. I am pretty sure it helps a lot making the life harder for people evading taxes, and to some extent the availability of a standard machine-readable format makes it easy to do accounting. My wife sells videocourses online and I developed a thing that automatically issues invoices as soon as people buy a product (with some human supervision, mainly to avoid the machine doing havoc is some exceptional situation happens; normally it is just "click a button to send the invoice"). The invoices are then automatically available to the accountant for doing accountant things.
Not sure it is a good idea. It might be more flexible when you issue an invoice and have to modify it, but first it would enable fraud, and second it would mean that you have to monitor incoming invoices to see if anything changed and account for that. I think it's better to ask people to just emit correct invoices: if you need to invoice a bit more you issue another one, if you need to invoice less you issue a credit note. If you can't do that you need to work on your business processes.
And then just wait until you meet Invoicing's annoying cousin Purchase Orders (PO). THere is a PO. Can I pay this in multiple invoices ? Sorry the PO is not approved yet. We cannot accept an invoice. Sorry the Invoice doesn't have reference to our PO. Can you fix that please ?
Hey @codegeek! I'm Anh-Tho, one of the co-founders of Lago.
We're working on making the 'CPQ' : Configure Price Quote journey simpler, and this includes the PO dead end.
We're on a mission to make the pricing stack more open and customizable for companies (hence the open-source angle), and we're starting with the billing system.
Join the journey, we'll share our repo soon, and hopefully we can address these painpoints faster with the community contributions too!
Yep. Invoice software is country specific. One can sell invoicing software to several countries, it just can not be the same software. And no, you can't just abstract the differences, because the invoices focus changes widely.
At least we are in a situation where the seller is almost only subject to the laws of the seller's country. There are some exceptions, but one can mostly deal with those (the EU has plenty, the good news is that if the seller is not also on the EU, most do not apply).
Also, I haven't seen a country accounting system that made accounting papers inherently expensive. Some make refunds very expensive, but not the papers. It's more a matter of badly designed software and processes.
I work on a payment system that invoices consumers on behalf of other companies and pays out the money to these companies by splitting the payout on multiple partners (luckily I do not handle the support and follow-up). The system have ability to refund invoices and customers some times end up paying more than or just parts of the invoice. On top og all this it integrates with several old 90s systems with poor datetime handling and poor uptime (some times a windows xp box in the cudtomers offices). It also handles card payments and over all, by far the hardest thing to get right is the invoicing. Its just so extremely fuzzy and time sensitive.
And most big companies who agree to pay you net X days, that usually is after the presentation of a correct invoice. The invoice doesn't get to them, or it isn't right the clock doesn't start for them to pay you. Getting invoices wrong can quickly result in major cashflow drops.
I'm Anh-Tho, one of Lago's co-founders here.
Indeed, from our experience people see 'billing or invoicing' as a monolith block, whereas there's a whole 'pricing stack', billing > payment > invoicing > cash collection + accounting + CPQ + sales commission.
For cash collection, we mentioned the tool used by Lattice called Upflow which helps to manage account receivables.
Hi!
We decided to aggregate all costs of a "billable period".
Imagine you bill your customers monthly (the billable period), all the charges (usage-based features + subscription) will appear as line items of a single invoice.
This enables you to gather all the fees of a period into a total invoice, but still be able to provide granularity to your customers (breakdown of all the fees to be paid).
Hi, customer here. We'd like to change our billing period to start on the 31st of every month, and we'd like to pay 90 days in arrears, and we'd also like you to invoice us ahead of the billing month. Oh, and we're big enough that losing our business will end your startup, so don't get it wrong. Thanks!
Hey, Anh-Tho, just as a point of feedback, since you're leaving a lot of comments in this thread, it's not necessary to introduce yourself in each one. Most folks will be scanning the whole thread and seeing your introduction gets repetitive and breaks the conversational tone and makes it overly commercial. Thanks.
I was illustrating the point that customers are often unreasonable about billing, and there's no magical solution that fixes the problems. The answer is really to try to make sure you're not overly reliant on a single customer. That's hard as a startup though especially if you're in B2B.
Hey cm2012, I'm one of the cofounders of Lago (my business partner wrote this post).
Actually even if you're incorporated in the US, if you serve a client in EU for instance, the VAT rules of EU apply to how you're supposed to invoice your customer, beyond a certain transaction limit.
So... unless you're based in the US, and only serving US-based users, it gets complex very fast!
If you wire your dollars onto US soil, for a service performed in the US by US business, good luck getting the US legal system to enforce upon that US business whatever euro-cucked invoicing scheme is called for.
This doesn't matter. For B2B, if you don't show your EU customers a valid invoice, they simply cannot pay you.
It's not EU governments or post-purchase issues you have to deal, most of the time - it's trying to persuade a large accounting department to pay you unaccountable money. If you can't follow their invoicing requirements, it's just not going to happen.
Do people ever stop and wonder WHY in nations like Portugal the informal economy is roughly DOUBLE of say the US? When every invoice must be available to the government, what actually ends up happening is non-conforming invoices either get made up by the customer or the money magically flows out under some other auspice.
Making it literally illegal to accept an invoice that is legal in the country in which you obtained it borders on logic even my toddler can understand is absolutely begging for bad business climate or tax evasion.
What is the mechanism for French government to subpoena a non-EU business to find this invoice? If the customer (instead of vendor) produced an invoice that matched their bank statements and non-conforming receipt, hypothetically, would anyone really know the difference?
Probably they wouldn't as full audits aren't that common, but audits do happen and most accountants won't care about your purchase as much to personally commit a felony and forge documents for no good reason (accountants do have personal responsibility, and every accounting course reminds wannabe accountants that "the boss ordered it" is not an excuse) so they simply say that they can't/won't do it and if the vendor can't send a satisfactory invoice then they won't do business with that vendor.
How would a French audit uncover anything wrong with a conforming format invoice under the name of some random American company that exactly matched the bank statement, physical goods, and customs paperwork?
I don't think US has many relevant freedoms left. Some people cling very hard to legacy 18th century ones while the Moloch just gobbles up all the new ones stemming from progress.
That american exceptionalism approach will work with private citizen customers. With business customers, leaning back in the legal framework encouraging tax fraud will not fly. They just won't buy from you then.
That's why any US company wanting to do business in Europe either has an European subsidiary, or follows something that's compatible with EU invoicing schemes.
>. With business customers, leaning back in the legal framework encouraging tax fraud will not fly.
Yes which is why in nations like Portugal, where any business invoice may be subject to accountability to government, there totally isn't a massive informal (read: tax-evading) economy to deal with the fact that the government makes it literally impossible (at least in above words) to accept an invoice legal in the jurisdiction in which it was issued.
It's not illegal to pay an US company with an US invoice in the EU. (HN likes to invent problems where there aren't, and companies do that all the time). It is not even limited to the US, most other countries can't/won't follow the format.
However there might be extra steps in adding those invoices to their accounting. For example, when import, the buyer will be charged the import tax (instead of having it added to the invoice)
The informal economy of Portugal has nothing to do with the above btw since that has nothing to do with American invoices (and you can bet German rules are not much simpler) - not saying the bureaucracy isn't, most of the time, stupid. The US also has it fair share of stupid crap that people have to deal as well but it is "transparent" to most Americans.
You keep bringing this up and it's simply not true. The EU has a single set of VAT invoice requirements that applies across the EU (the MOSS invoicing standard). Any VAT invoice that satisfies these rules is legal in all EU countries (https://eur-lex.europa.eu/legal-content/EN/ALL/?uri=CELEX:32..., article 226).
My company does plenty of business with EU businesses and we use a single standard EU VAT invoice without issue.
It's not literally impossible - the simple solution to standard invoice being unacceptable is to issue a different invoice that matches the requirements, and almost every vendor is happy to do so in order to make the sale.
Also, the informal tax-evading economy relies on personal contacts and 'mutual understanding' - it's not easily accessible to a foreign vendor, and when foreign vendors do want to access that economy, it requires much more adoption of local customs than just making a different format of invoice.
Yes literally impossible to take something in a format legal in the US, that doesn't match the foreign requirements, based on European testimony above (the exact truth of which IDK).
Informal tax-evading (when the seller isn't evading, just the buyer) doesn't require personal contacts. This is just naïve thoughtless statement. It happens all the time. Example: business owner goes to Panama where they know no one. Buys a pallet of llama wool, seller gives a non-conforming receipt. Buyer goes back to France, imports the pallet as "cotton" and creates a fake invoice showing the Panamanian sold cotton. Seller then sells llama wool on the streets for cash, marking in the books that they sold "cotton" for significantly less. They then use the on-the-books "cotton" proceeds to buy a shit-wagon car or something, and fix it using the unrecorded cash on the side. They sell the now nice shit-wagon and record the proceeds as profit. Now all the money for the llama wool is accounted for.
Cross country tax-evading is only assured in this case to require personal contacts when the tax evading happens on _both_ sides. When it only happens on the EU side, there's no need for personal contacts on the US side.
> Buys a pallet of llama wool, seller gives a non-conforming receipt. Buyer goes back to France, imports the pallet as "cotton"
Customs catches him (distinguishing cotton from non-cotton is surprisingly easy, so is forged documents for invoicing and freight papers, especially given that Panama is an unusual country to export raw cotton - or raw wool - from), he is now in prison for 5 years for tax fraud and document forging, llama wool is confiscated and auctioned off to legitimate sellers.
Maybe you can come up with a better example then :) Here in the US pallets of cocaine regularly make it through customs. Our customs officers are generally one rung above high-school dropout. They'd generally be lucky to distinguish heroin from a pallet of sand, let alone cotton from wool.
Not in the export/import business myself, just passed through customs enough to see just how truly stupid and vapid these officers are, combined with the truly insane amount of import/export volume each one is responsible for. In the US distinguishing types of fabrics and ensuring various legal substances that look vaguely similar actually are what they say they are is near the bottom of the priorities list. I don't have a lot of experience with EU customs (except see last paragraph).
I know people want to believe customs is some highly intelligent caring group of individuals who are sleeplessly guarding the country and the purse in a carefully planned and executed manner with a fine-toothed comb. Anyone with this belief has probably never crossed an international border. In practice it's more like the mental equivalent of a 4 year old set loose with a completely unreliable "drug dog" that alerts on a grandma who is ruthlessly interrogated while one guy with llama wool and 10 pablo escabars pass on the other side.
I can recall one occasion where I stepped directly from fucking IRAQ into EU and not a single customs officer even looked at me. Not one. Just a stamp without a single question. I could have been carrying literally anything and no one cared. I could have been coming from Iraq for any reason and no one gave a fuck what that reason might be.
Yes. It would be even larger if US companies couldn't accept foreign invoices without being in a special format. Does tax evasion in the US somehow disprove tax evasion in Europe?
The difference is marginal at best. Most of the requirements are obvious and never/rarely change, like your address or the date. And adding a an incrementing number to a set of documents isn't exactly rocket science, either.
In this particular case, do you think non-US governments could protect the interests of consumers in their jurisdictions in a way that is less unfriendly to the businesses that want to sell to them?
In my experience invoicing, and really all 'printable' documents is the land of "oh someone did something wrong put X on the document". And then again and again and again... And "this is two pages long that's too much" and on and on ...
It's bike shedding insanity with no ideal or end in sight. Every change is arbitrary with no real measure of success.
I swear the only time anyone LOOKs at these documents is to bitch about them.
Oh man and just as if I summoned it someone just sent me a ticket about something on an invoice.
Just because you don't understand invoicing doesn't mean that the concerns that appear trivial to you are actually trivial.
From the perspective of someone who works with the people who process the invoices, putting "X on the document" and "two pages long" can be a huge deal when you have to deal with hundreds of invoices or when "X" can mean that an invoice must proceed down a different processing path. These aren't bike shedding concerns; they affect the actual processing of the invoice. In many cases, these concerns affect the validity of the invoice, meaning that the recipient's obligation to pay (or the associated deadline) is not triggered.
And doing something wrong on an invoice is never bikeshedding. An invoice is a legal contract, and in the E.U., an invoice is an unmodifiable document.
They're trivial... when you make the same change to add something, remove it, add it, remove it and hear that it's all being done "because X" and "X" never stops, it's clearly not working and the changes are trivial.
It sounds like you simply don't understand why they're doing it and you just assume that they're trivial because you have no knowledge of the domain.
Off the top of my head, I can thing of a dozen reasons for why they'd require something to be added, then removed, then added, etc., from one invoice to the next.
- Changes prompted by common vendor mistakes: DBA vs Legal vs Tax name, Tax vs business ID vs tax account id, projects vs Departments vs Accounts vs Budgets
- Changes prompted by compliance needs: business type (which governs the type and level of compliance required in most jurisdictions), changes to invoicing laws, changes to tax compliance laws
- Changes prompted by business needs: changes to the company's PO/invoicing/expensing process, changes to the company's financial, ERM, or payment processing software or service provider, one-off large expenses that aren't adequately handled by the existing data form; changes to financial modeling
- Changes prompted by marketing: new logo, design, or template
- Changes prompted by legal: new court rulings, etc., affecting legal's approval of the existing template(s)
- Changes prompted by employees: form is too complicated, form is not complicated enough, form doesn't capture my department or project's needs
The problem with an all inclusive form is that it is too complicated for most vendors and they end up filling it in wrong (requiring several rounds of review by the payor company), but too simple a form and you end up needing to make a lot of changes like the one the parent was talking about.
You could do multiple templates, but that just multiplies the work, and makes it more difficult for employees to figure out which template they should be using, and so they'll all end up using whatever random template they find first leading back to the One True Template and you're back to square one again.
And yes, all of the examples above are based on real life examples.
> You might be sending a truckload of expensive accounting papers to your customer every month, one per transaction. And each of those pages was printed using government prescribed software from oddball vendors you must use or else.
I guess that's good for employment numbers? There's really two ways to create jobs, innovate or regulate. The US and the EU have apparently chosen very different paths. With every country having it's own special snowflakes laws, there's a reason EU founders always try to come to the US first.
In the US, an invoice is just a weird PDF that you might glance at before sending off to your accounts payable team. But in other countries, especially those that use VAT style taxing systems, an invoice can be a legal document that expresses costs and taxes in a legally prescribed way for accounting purposes. Many countries have prescriptive rules over how you invoice, who can write invoices, when you can invoice, what goes on an invoice, etc. And every country does it differently.
Are you building a service that charges incrementally many times per period? Or even worse, refunds incrementally? You might be sending a truckload of expensive accounting papers to your customer every month, one per transaction. And each of those pages was printed using government prescribed software from oddball vendors you must use or else.