[spchampion2]

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.

[vidarh]

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.

[AnhTho_FR]

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!

[christkv]

I definitively am interested in a couple of months. I rather not build our own if we don't have too.

Do you have any early guides or api docs to take a look at. Our use case.

1. Base service fixed packages (based on users with volume discounts)

Extra costs 2. Extra storage space usage 3. Add on services (fixed or usage billing) 4. Invoicing third parties (reselling content)

[bombcar]

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.

[deltarholamda]

I said, over and over again, that moving away from goats and salt as currency was a mistake, but nobody listened to me.

[D-Coder]

But the different conversion rates for each kingdom/duchy/province/parish were a nightmare even then.

[folmar]

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.

[Rafsark]

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…

[ozim]

Yeah - and simply creating an invoice is creating taxable income in EU - if customer drags their feet you still owe VAT to the taxman.

If you want to change invoice you have to make a special "correction invoice" because changing "real invoice" is a criminal offense - fun things :)

[friendzis]

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.

[hnbad]

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.

[vidarh]

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.

[hnbad]

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.

[trollied]

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.

[Rafsark]

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

[trollied]

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.

[radicalbyte]

A credit note. How the ** do you handle it in the US without issuing credit notes in your bookkeeping?

[indymike]

We issue a credit note*

* Except (these aren't the right thing to do, but I've seen it in the wild many times):

- When someone in sales issues an invoice with a negative amount on line 3. Hey, if I take payments with invoices, why not give back?

- When someone agrees to settle up by providing free services and throws it on the next bill.

[lowercased]

> 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.

[dawkins]

Invoicing gets even better in countries like Portugal, where you have to send to the tax authorities every invoice that you generate.

[giomasce]

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.

You can find the XSD here: https://www.fatturapa.gov.it/en/norme-e-regole/documentazion...

[kinj28]

They should rather give a service to issue /cancel an invoice and people will happily use the service

[giomasce]

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.

[codegeek]

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 ?

[refurb]

Annoying but necessary if you dig into it. If don’t we’ll you avoid paying random invoices emailed to your invoice processor!

[AnhTho_FR]

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!

[marcosdumay]

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.

[wonton53]

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.

[johnrgrace]

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.

[AnhTho_FR]

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.

[Rafsark]

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).

[onion2k]

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!

[AnhTho_FR]

I'm Anh-Tho, one of Lago's co-founders here. Thanks for sharing! What did you do then? I'm curious!

[bckr]

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.

[burnished]

I fear if they did not they'd be accused of something else. I agree with your observation but I don't think there is an obvious solution as you imply.

[bckr]

They can disclose their interests without the repetitive intro. But for the above comment, just asking a question, even this is unnecessary.

[AnhTho_FR]

Noted thanks! It's my 1st post on HN, so I appreciate the feedback.

[onion2k]

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.

[cm2012]

Just one of many reasons its easier to do business in the US

[AnhTho_FR]

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!

[yupper32]

That's their point, they said "do business in the US". You're saying the same thing.

[notch656a]

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.

[pimterry]

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.

[notch656a]

>they simply cannot pay you.

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.

[sbierwagen]

Feature, not a bug. If there's pervasive lawbreaking, then the officials can collect more bribes.

[AnhTho_FR]

I'm Anh-Tho, one of a co-founders of Lago. I'm French, and I confirm, in B2B, no invoice (that is compliant, not a mere receipt) -> no payment.

[dkjaudyeqooe]

European bureaucracy is out of control, and that's just the west. In the east and former Soviet states, it beggars belief.

[DocTomoe]

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.

[notch656a]

>. 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.

[raverbashing]

People are mixing up things here

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.

[gamblor956]

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.

[PeterisP]

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.

[orf]

There isn’t a massive tax evasion economy in the USA?

[IAmEveryone]

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.

[mitchdoogle]

Protecting consumers is always bad for business

[baronswindle]

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?

[duxup]

Not even legal issues.

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.

[gamblor956]

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.

[duxup]

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.

[gamblor956]

No, the changes aren't 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.

[BeFlatXIII]

> dozens of reasons

Then why not list them right here, right now?

[gamblor956]

- 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.

[duxup]

> It sounds like you simply don't understand why they're doing it

I don’t know why you would think that considering I work with them and you do not…

[gamblor956]

I work with the A/R and A/P teams all the time. It's a large part of doing tax in-house.

[throwaway6532]

>And every country does it differently

Seems like the real world is just choc-full of Liskov Substitution Principle violations :P

[908B64B197]

> 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.