Archives For Research

This month marks the sixth anniversary of Expensify. In may 2008, David Barrett got the idea of a world where expenses reports don’t have to suck. With this idea in mind he rallied the troops and founded Expensify, and for six years we’ve been experimenting with countless ideas on how to make expense reports not suck.  Continue Reading…

Calling All GL Coders

Jason Mills —  January 12, 2012 — 3 Comments

Yes, accounting and finance departments, we’re talking to you!

With 2012 in full swing, everyone at Expensify is excited by the opportunity to make this year even better. Don’t get us wrong, 2011 was awesome! But we’re a startup, and re-thinking the old to build something new is an oft-repeated mantra. As larger and larger companies increasingly drink the Expensify kool-aid – or our own Expensify beer thanks to a resident brewmaster – our sights are squarely aimed at the scary-sounding world of “enterprise accounting.”

As you may recall, in late-2011 Expensify unveiled functionality that allows anyone to create and edit a very flexible CSV export file. This functionality enables our system’s Categories and Tags to speak the parlance of enterprise accounting and CRM packages. It’s called GL Mapping, and we’re super excited about the potential of this functionality, especially in the context of our self-service, bottom-up adoption model. With that said, we are still in the exploration stage when it comes to enterprise accounting and ERP systems, and for some reason, it conjures images of scary pumpkins. So we thought we should take up some white space to learn what’s out there. Thus far, we’ve talked to customers that use Sage, SAP, Oracle, Netsuite, Intacct, and many others.

But more than names, we’re interested to learn about the types of accounting configurations that we need to support. Past conversations have worked out how to export Expensify’s data into a MySQL database before eventually feeding this information into an accounting package. This was luckily solved by a bit of accounting triage; in other words, correctly mapping the columns in the company’s database. We’ve also seen customers that must track a variety of inter-related GL Codes, both at the expense-level and at the report-level, and this has required a good deal of problem solving for all involved.

This brings us to the interactive part! We’d love to hear from you about your GL setup.  Specifically:

  • Do you have any pain points with Expensify’s existing GL functionality? What are they?
  • Do you feel like Expensify doesn’t support your accounting package or setup? Why?
  • Is accounting integration the most important factor in your purchase decision, or does other functionality like automation matter more?

Please join this conversation in the comments or feel free to email jmills@expensify.com.  Thanks!

Remember when Danger lost all their backups?  At that time I wrote about Expensify’s massively redundant, multi-tiered backup system (to two remote locations in realtime, and to two more remote locations nightly) in a passionate appeal to sanity.  Soon after that I turned off my Sidekick for the last time, and turned on my shiny new Palm Pre.  (And I ain’t going back!)

But now I read that RockYou has compromised the usernames and logins to 32 million social networking accounts because they didn’t encrypt a damn thing?  Come on people!  Encryption is so… I don’t know, 1942?

At Expensify, we take security incredibly seriously.  We spent pretty much the entire first year building a geo-redundant, PCI compliant datacenter that achieves… actually, now that I think about it pretty amazingly high uptime, while simultaneously remaining super secure.  It wasn’t easy.  But that’s our job.  It’s not an optional thing.  Either you do it secure, or you don’t do it at all.

In our case, we use a type of encryption called “split knowledge, dual control”.  It’s more complex than this, but we basically split our master encryption key in half, and store each half in a different safe deposit box (Witold controls one, I control the other) such that nobody ever knows the whole thing.  This means nobody can decrypt our data alone, not even me.

Additionally, this key is assembled in memory on our servers using a type of “turn two keys simultaneously” system (akin to a nuclear launch panel) and never written to disk.  So even if you physically stole the servers out of our hardened datacenters (something you’d be a fool to try), they’d be little more than really expensive paperweights.

Anyway, I understand social networking data isn’t as sensitive as financial data.  And I understand most web developers don’t know how to deploy and maintain realtime distributed transaction layers.

But I don’t find those very satisfying excuses, and I doubt you do either.