This is my OLD blog. Thew new one can be found here

Yet another online invoice billing tool

On a personal note..

My company fortrabbit proudly launched our new online billing tool. Granted, this is not the first, but in Germany, the market is quite new. The software is implemented in our MISH system, which is a perl/catalyst application running also our hosting control panel. Speaking of which, our hosting pricing is based on a “pay per usage” model, which produces very different invoice amounts each month. Being too lazy to do this manually and also being those kind of “we can do this better” developers, we wanted to create the invoices by ourselves and not wanted to rely on a third party API (also in Germany invoicing follows very strict specifications, so most of international / american tools could not be considered at all). However, having this done, we naively thought: “Why not add a nifty interface and allow anybody to use it?”. Well, that was about a year ago. Of course, not the whole time was spent on this (most of the last year’s time was spent implementing new features for our hosting, extending our hardware and fulfilling customer requests), but i think at least three months full time were dedicated to the e-billing part.

However, this blog is not about marketing announcements, so i will highlight two implementation and two conceptual issues and our solutions which may at least provide some help ..

Tricky implementations

PDF creation

The most time wasting effort was probably the PDF creation itself (or research and test-implementations around that topic).

Originally, we considered using some perl PDF API (PDF::API2, CAM::PDF, PDF::Create, PDF::Reuse or even PDFlib) but we struggled with the terrible annoying “put pixel”-like interfaces. You have to implement the whole business logic (document layout, table structures, repeatable contents, page-breaks) yourself, from the scratch. Then we found Apache FOP, which is a great piece of software, very easy to use and, with XLS/XST, very scalable. But there is a downside, which led us to re-think the whole matter about two month ago from the scratch (again): the performance. FOP is very CPU/RAM intensive and quite slow. So again, what to do ? This time, we did not let ourselves get scared by the effort and wrote a PDF-document-creation abstraction (PDF::Document, not yet on CPAN). It can use different “distillers”, for the actual creation and can define document types (eg: PDF::Document::DIN676B, which creates document matching the German DIN 676 B business letter norm.. yes, in Germany is a norm for everything). For the distillers, we first went with PDF::API2 (or the newer PDF::API3 via compat layer) cause it is very mighty and has an awesome documentation. Soon, we ran into another problem: Everything worked flawless .. but still slow. The problem was: PDF::API2 is native perl and what you can safely call a huge module (in lines of code and size in RAM). Another problem was, that the created PDF documents were way bigger then the ones from FOP (yes, we are quibble about this kind of stuff). Then we found PDF::Haru, which is a perl-wrapper for the c written libharu. It is incredible fast and creates very tiny PDF documents (a whole invoice from about 2kb). In two words: love it. In the end we have a document-abstraction, where we can (more or less) easy define the document layout and rely on an open source PDF library for the creation, which is also is very fast.

Sending invoices

Having an interface where you can click around and finally create a PDF of your (invoice) data is only half of the game. In order to get your money, the recipient has to receive the invoice first. Our customers are able to download the invoices from our web interface (which would be sufficient, afaik). But, despite that freshbooks cheers this concept, in Germany, most people expect to get the invoice via snail mail or at least signed (we call it “qualifizierte elektronische Signatur”) PDFs via mail. This time we stepped back and used a third party API: pixelletter. Those guys are great. They have a simple HTTPS/XML API (also a mail gateway) where you can upload your PDFs and either send them via snail mail, retrieve a signed PDF for mailing or even send the document to a fax number. This, of course, saved a lot of time. They are very reliable and we never had any technical issue with them. There is of course a perl module on CPAN: WWW::Pixelletter.

Conceptional problems

Sharing / multi-access / coworkers

When we began with the concepts of our e-invoicing tool, there weren’t much other tools (in Germany) around. So we (luckily?) had to define the best-practices and how-it’s-done by ourselves. The idea of most (all?) other invoicing tools in Germany of how sharing should work goes like this:

  • There is one user with an account which represents a company.
  • The user can add additional login credentials, which also can login to it’s account (=coworker).

Maybe having heard this before implementing our idea would have saved us some time.. However, this what we did:

  • There is one user with an account.
  • The user can create multiple companies (aka sender address of the invoice).
  • The user can invite other users (e-mail addresses) to access a single or multiple companies (=coworker).

Why did we do that? In the early alpha of our tool, we gave access to the guys in our office. All of them are free lancers and somehow cross-related in some ventures and most had multiple companies (eg: i do work as a free lancer and also for fortrabbit – so two companies i might write invoices from). With our model, you do not need to hassle with multiple login/logout to switch to someone else’s company, you have access to. Also you do not need to signup (and pay) multiple times, if you have multiple companies. The downside of our approach is, that each user has to create an account – even if he only wants to access someone else’s company, has none himself (and therefore does not pay us a dime).


Free of charge is a thing where the opinions differ greatly. On the one hand, you see a lot of companies for which it perfectly worked out, on the other hand, you need to burn lots and lots of money until it finally somehow pays off (or not).

For invoice tools, most (e-billing) providers offer some kind of freemium entry-level product, none is totally and forever free. What you will get for your zero-money and when you have to begin to pay is very different. One allows you not more then three different customer, before you have to pay on a monthly basis, the next does not give you SSL encryption and prints its advertises on your bill and another one will give you a free period of time, as long as you do not use sharing. If more so it differs when you look at the further pricing models.

When the time came for us to define our final prices, we had a look at all the different models out there and were not very happy with any of them. To begin with, we are a small company and require an “organic growth” strategy (in short: more customers -> more resources to invest in work/hardware -> more customers -> ..) , so we cannot afford to give out everything for free. Also, we really wanted to give the user a useful service, even if it’s for free. So restricting any function in any matter was out of question. What remained was limiting some amounts; in our case: amount of createable documents. The time period, in which you do does not matter. The amount of clients you have does not matter. The amount of companies you have or can access does not matter. The amount of coworkers you invite does not matter. After the first created (=not draft) twenty documents (invoices or estimates) you can decide yourself whether you stick around or go your way. Still, this is not perfect, but we think it is the least bad one.

Final words

There are tons of more problems and struggles i could write of, but i will leave it at that. I swear, the next article will be about admin stuff again ;) (probably ceph.. i’m not sure yet)

By the way, the service is called Fortrabbit WebRechnung (~WebInvoice)