Thoughts on job tracking and invoicing

I’ve been looking for a good job-tracking and invoicing program for a long time. I’ve looked at just about everything, and nothing suits my particular needs. My needs are a little different—almost none of my work is billed by time but piecework instead (support for this kind of thing is often an afterthought) and I need support for multiple currencies (this is rare).

I’ve tried using Apple’s Numbers spreadsheet app. Spreadsheets in general have one big thing in their favor: they impose no assumptions on you. The flipside of that is that you have to build everything from scratch. There are a few aspects of job tracking where you’d prefer for your program to have made those assumptions for you. A bigger problem I had with Numbers in particular is that it corrupted my job log spreadsheet, which is a colossal PITA. A more philosophical problem is that spreadsheets are basically flat-file databases, and a proper job tracker really needs a relational database behind it.

Watching Gwen figure her work on a letterpress printing project was a lesson in how very different the job-tracking requirements for two solo freelancers can be. Ideally, one app would have the flexibility to meet these different needs. I’ve been giving the subject some thought, and what follows is my attempt to crystallize them.

There are a few assumptions that can be made for a job-tracking and invoicing app—a few basic structures that everything else can fill in around: I propose four basic record types: Clients, Projects, Events, Reports. Each of these will relate to the others types in specific ways, but in a smart job-tracking app, the user would have the option to add fields to each as needed, giving it the flexibility of a spreadsheet and making the app as extensive or stripped-down as desired.

Much like a spreadsheet app, there would also be several basic field types that the program would be able to manipulate intelligently, such as time and duration, monetary amounts, etc. These would be used as the building blocks of records.

Clients are obvious. Ideally there would be a way to enter data for multiple contacts within a single organization. Fields that might be added to a client record: name, client code, e-mail address, phone number.

Projects, also obvious. A project is everything that can be grouped under one job number. It is a set of events that is tied to one client. It might be useful to be able to break large projects into phases, so that each phase could be invoiced separately, but that’s beyond what I’m considering. Fields that might be added to a project: job number, client’s job number, PO number, associated files, status (quoted, underway, completed, invoiced, paid, overdue).

Events are the meat of the job-tracking app. For my business, almost every job consists of exactly one event (translating a document). As simple as that is, the fields that would go into an event record for me would vary somewhat from client to client. Some of my clients expect me to bill them by the word, some by the Japanese character, and some by the “page”, where a page is a calculated value based on words or characters.

For a letterpress job, Gwen might have several types of event records: client meetings; ink, paper, and plate orders; time spent in design; client review; time spent on press.

All of these are very different kinds of record, but there are certain predictable kinds of fields that could be baked into the app and made available to any event record: date, duration, billable amount, expense amount, etc. Plus other more generic data types, like text, integer, boolean, etc.

So I could create a “translation” record type with fields like description, word count, rate per word, line total (a calculated amount of rate * word count). To deal with a different client, I might have another with description, character count, page count (a calculated amount based on characters / some constant), rate, and line total. I might even want to track both words and Japanese characters as a way to collect statistics on the relative lengths of Japanese and English documents—this would be useful when estimating.

Gwen might have a “meeting” record type with description, date, and duration, and a “supplies” record type with description and expense amount.

This all describes how information gets into the program. The way information would get out would be through reports.

Reports would be queries against the other types of data. Invoices are just a special type of report with some of its own bookkeeping logic attached. For example, I might structure an invoice as being “all projects with status=completed for client X.” Likewise a quote or dunning notice. Internal report might show how much I’ve made from all clients in a month, or a year, or how much is overdue. If I got fancy and started keeping track of the hours I work, I could get a report showing distribution of words translated per hour.