Refining the scope

This post explores some of the reasoning and objectives behind Invopop as the project is being built. Originally, this information was intended for an “about” page on this website, but it occurred to me that over time, a lot of these ideas will change as the project matures. Having a permanent reference with a timestamp felt like a more honest approach.
‍
Invopop is being built by developers for developers to try and solve the many problems we currently see around turning sales into fiscally valid invoices:

• creating PDF invoices is time-consuming and it’s rare as developers that we can justify spending large amounts of time making them look good,
• generating electronic invoices with most of the current standards based on XML is complex and unappealing, mainly because XML doesn’t represent the way objects, arrays, strings, and numbers are dealt with in code. Add in complex schemas and namespaces and you end up with documents that are hard to understand, debug, and parse reliably,
• discovering local validation rules and keeping up with tax rates takes considerable effort, despite the fact this information is public,
• digital signatures are great, yet the amount of effort required to get them working (see Canonical XML) means that most developers try to avoid it if they can,
• more and more countries are now requiring electronic invoicing with digital approval from tax authorities. Most of Latin America is like this, and in Europe, the trend has started with Italy and Portugal. Integrating with different providers in each country, each with its own quirks and undocumented features, can become time-consuming, and of course, a solution in one country generally can’t be re-used in another,
• most companies aspire to go global eventually, yet each country has it’s own rules and regulations; countries like Brasil even have different invoicing and tax rules on a per-city basis,
• as a project becomes more successful and sales increase, forwarding invoices to accounting services or ERP platforms quickly becomes necessary. This is yet again another integration that needs to be built and maintained.

Our objective at Invopop our aim is to try and ease the pain with a two-pronged approach:

• Firstly we need to make creating an electronic invoice much easier. We’re building a standard library in Go that once published as open source can be incorporated into your code directly, used as an internal micro-service, or hosted on the Invopop platform. The idea is that this software, which we’re calling GoBL, defines global tax rates, invoice document structures, validation rules, and digital signatures, so that creating a digital invoice in JSON is quick and straight forward, no matter where you are.
• Secondly, the Invopop platform receives the GoBL JSON output, and converts the documents into whatever format is required; PDF for humans, local XML e-invoicing formats, sending to the government for signing, or forwarding to your account or ERP platform.

Sounds straightforward, and the end result for developers should be, but behind the scenes, we’re very aware of the complexities of building multinational software. The key to Invopop’s success will be in building centralized and global teams capable of adapting the product locally so our customers can focus on one single integration with us.
‍