Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Billing systems are a nightmare for engineers

getlago.com

Post reply on HN
Print view View original

361–370 of 372 posts

Re: Billing systems are a nightmare for engineers

#361

Post by elevation »

btilly wrote: post #259

Wait until you get into the complexities of taxation. If you think you know them, pay attention to https://twitter.com/aotearoa_ben/status/1526786701750050817 . That's a law that changes the tax rate if 1. The purchase happens in Texas. 2. The payment cleared in a specific 2 day period. 3. The item cost Seriously, calling out just one example, https://comptroller.texas.gov/taxes/publications/98-490/scho... points out…

Even when the laws are comprehensible and you're not running at scale, existing accounting systems make supporting simple new requirements difficult.

Imagine a US LLC setting up their chart of accounts to track IRS deductible expenses. Coding expenses into this 17-account schema in the normal course of book keeping means taxes can be filled by copying the account totals into the corresponding IRS form field.

But later, the business wins an federal contract which reimburses certain "R&D" expenses and possibly some "overhead" expenses. Now not only must every expense must be categorized with one of 17 expense categories for the IRS, but it must also be categorized with one of 3 categories for our federal contract purposes. But wait, a small business loan application may require profit and loss broken down by a different set of categories. New and local tax authorities may impose other categories.

One way to address this complexity explosion is with multiple instances of the same accounting software; each imports the same bank account statement, then justifies it against a chart of accounts. But many businesses will break out Excel and hope there aren't too many expensive errors.

If new regulation is inevitable, why does our software pretend otherwise?

Re: Billing systems are a nightmare for engineers

#362

Post by btilly »

vonunov wrote: post #342
fuklief wrote: post #336

Earlier quoted context omitted.

You might be interested in [Catala]( https://catala-lang.org/en/ ), a domain specific language for implementing legislative texts. Iirc, they have worked on the french tax code, and are starting on the us one now.

Gee, that's bold, I feel like "try writing in plain English" is already asking a lot of the legal profession (fortunately some of them are taking care of asking it of themselves). I wouldn't want to push it!

Here is an irony. If most contracts were rewritten in plain Spanish, they would be understood by a higher portion of the general US public than the current legalese!

If you believe the statistics on literacy and multi-lingualism, it's a tossup as to whether Chinese or legalese is more widely understood.

Re: Billing systems are a nightmare for engineers

#363

Post by vidarh »

hnbad wrote: post #351
ozim wrote: post #48

Earlier quoted context omitted.

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

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.

Re: Billing systems are a nightmare for engineers

#364

Post by bcrosby95 »

BeFlatXIII wrote: post #355
bcrosby95 wrote: post #58

I've had to deal with subscription based billing, and in my experience it wasn't a nightmare. There are some corner cases, but, those exist in every domain. And the stakes are definitely raised since you're dealing with people's money. Usage based billing sounds like a nightmare though. Taxes in the USA are a nightmare too. I have a friend that lives on a street, and for one side the tax rate is 7.5%, and the other s…

How often to neighbors on that street ship their deliveries to one another to cheat on taxes?

No company got it right - they all charged the same percentage regardless of which side of the street you lived on - so you didn't have a choice in the matter.

Re: Billing systems are a nightmare for engineers

#365

Post by gamblor956 »

BeFlatXIII wrote: post #354
gamblor956 wrote: post #156

Earlier quoted context omitted.

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.

> dozens of reasons Then why not list them right here, right now?

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

Re: Billing systems are a nightmare for engineers

#366

Post by gabrielhidasy »

danielheath wrote: post #319
loloquwowndueo wrote: post #302

Earlier quoted context omitted.

Nah it’s not a US thing; tax codes are the same most everywhere.

I have never seen one quite as byzantine as the USA.

Come to Brazil, we have taxes on products 'circulating', moving your products between logistic centers is OK, but if the product is lost or stolen, taxes are due (as if it was a sale).

Some tax regulations were considered illegal by higher authorities, but that won't stop a tax auditor in a local level charging them and potentially closing down your business.

Re: Billing systems are a nightmare for engineers

#367

Post by hnbad »

vidarh wrote: post #363
hnbad wrote: post #351

Earlier quoted context omitted.

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 lon…

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.

Re: Billing systems are a nightmare for engineers

#368

Post by conductr »

jacobr1 wrote: post #350
conductr wrote: post #306

Earlier quoted context omitted.

True. One is a more realistic reality though. And it results in this thing only being built once instead of a massive headache for all. I have to imagine government workers are already writing software to identify if we’ve all implemented it correctly, when the could have just given us the code/api up front.

> I have to imagine government workers are already writing software to identify if we’ve all implemented it correctly Because of the jurisdiction issue, even if each local (and for each location all relevant governmental tax authorities) had a clear API, interacting with them all, and dealing with the interactions between them recursively, is itself a large problem. And from what I've seen from smaller jurisdictions,…

Since we're talking about a hypothetical solution, in theory this would have a spec and potentially even be further centralized.

I could imagine a world where the IRS ran the tax software for every taxing entity in the US. Each jurisdiction would have to configure their specs or potentially even codify the business logic. International would likely be tricky but it's similar to what is being done with ACH and other banking systems that are slowing moving to international. So, it's not impossible there's just not much of a push for it.

Re: Billing systems are a nightmare for engineers

#369

Post by tornato7 »

systemvoltage wrote: post #277
btilly wrote: post #259

Wait until you get into the complexities of taxation. If you think you know them, pay attention to https://twitter.com/aotearoa_ben/status/1526786701750050817 . That's a law that changes the tax rate if 1. The purchase happens in Texas. 2. The payment cleared in a specific 2 day period. 3. The item cost Seriously, calling out just one example, https://comptroller.texas.gov/taxes/publications/98-490/scho... points out…

We should demand governments to maintain and provide an API for their tax codes. Let them have skin in the game. If the taxes are incorrect, businesses can point out that it’s the government API’s fault. Completely developed in the open, and with full test coverage. This should be required to collect taxes. No API? No taxes. API down? Tax waived.

This actually sounds like a good use for smart contracts if we switch to a CBDC. Basically you pass your transaction through whatever state’s contract and it will automatically do the tax withholding for you.

Re: Billing systems are a nightmare for engineers

#370

Post by friendzis »

ozim wrote: post #48
spchampion2 wrote: post #5

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 ho…

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

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.

Post reply on HN