Archives For February 2011

Pro Tips: Receipt Browsing

micah —  February 28, 2011 — Leave a comment

You’ve got the expense, now what?

So you’ve found the expense you were looking for, and you want to attach a receipt to it. Clicking on the green “+” icon will bring up the View Receipts dialog, which has a thumbnail view of all of your receipts. The problem: many thumbnails don’t show the relevant information, such as the merchant or amount, that allow you to distinguish which receipt belongs where. The solution: browse full sized receipt images and attach it to the expense immediately.

Browse Receipts

Click on the image to get a blown up image of the receipt. Here you can easily view the merchant, date, amount, and any other information the receipt may contain. Hover over the left or right portions of the receipt and click the navigation arrow to move on to the next receipt. At the bottom you can also see which expense you are attaching a receipt to. Once you’ve found a match, click attach and you’re done.

Pro Tip

Much of the navigation in our site can be done with keyboard shortcuts. When browsing receipts, you can click the left/right arrows on your keyboard to see the previous/next receipt. You can always hit ‘esc’ to close the dialog.

We know many of you incur a lot of similar or repetitive expenses, and sometimes those charges can look suspiciously like duplicates. For managers out there who have to approve reports, these duplicate doppelgängers can spell trouble. But we’ve figured out a way to take you step by step through the audit process for these receipts that ensure no two people submit the same receipt image, and no single user submits the same receipt twice.

First: When you receive a report, confirm that the reported expense matches what is on the receipt image. While you probably treat this as due diligence already, we bring it up because it still lays the foundation for the entire audit and can allow you to catch any other line-by-line errors early in the process.

For example:

Our reported expense above matches the receipt listed below:

Second: On a periodic basis – perhaps monthly – visit your Expenses page and choose “Reported Expenses” on the left. This will display all expenses that were ever submitted for approval. If you set the date range to the month you want to audit, you can sort the table by Merchant Name by clicking the “Merchant” header, and then by “Amount.”  You can see this in the screenshot below:

Third: Scan down this sorted list for any transactions for identical amounts with similar merchants and dates. You can see an eye-catching similar expense below:

Fourth & Finally: Click on the receipt icon next to any matching/very similar transactions to see the receipt and verify for sure that they are different. Many receipts, for instance, have a transaction number or receipt number listed on them, so even if employees have made legitimately duplicate purchases, their receipts should be slightly different to allow for different transaction times and receipt number.

An important note to remember that Expensify helps you with: eReceipts can never be duplicate expenses. Because they are generated specifically by your credit card charges, they cannot be the same charge uploaded twice. So any time you see the “E” receipt icon in the receipt column during an audit, you can skip over those charges and rest assured that they are already audited and approved as unique charges.

And that’s a really basic way to use Expensify to audit your duplicate expenses!

Pest Control

micah —  February 7, 2011 — Leave a comment


There’s always an inexhaustible list of features, user requests, great ideas, and random goodies we would like to implement at Expensify. However, for the past few weeks we froze 99% of new feature development. Instead, this milestone we took a step back and tackled the most dreaded part of any engineering task: Bugs. That’s right, we voluntarily decided to take on the infinitely scrolling list of alerts, warnings, crashes, plunks, thunks, and uglies — and fix them all.

But why would we take a break from making the product bigger? Because first we wanted to make the product better. We wanted to get rid of all that code that was causing unexpected glitches or unacceptable results. The bugs were just plain annoying, both to us and to our users.

Bugging Around

Bugs come in all shapes and sizes. There were big bugs, little bugs, confusing bugs, convoluted bugs, old bugs, new bugs, obscure bugs, scratch-your-head-and-say-wha? bugs. But we tackled them all. I’ve asked the Engineering team for their thoughts. Here are the highlights from this season:

What was most significant/important/enjoyable bug you fixed this milestone?

The most fun one was moving database checkpointing into a different thread so our systems don’t occasionally halt for a second or two slowing down the site. But, really I imagine the one I’m enjoying most now was probably some trivial thing that reduced the number of my daily alerts from 9182739821731982739821 to just 123098218093.

I fixed the iPhone app from crashing due to low memory.

[Some engineering mumbo-jumbo... in sum, Nate] effectively eliminated the software constraints on the size of PDFs we can make.

Fixing small bugs that made a big difference, and fixing things that never worked in the first place. For example, detecting the file extension when uploading receipts before we try to upload the receipt to the server and make it crash.

How did you feel about this milestone?

[I enjoy the] fewer emails bugging me about junk. I no longer have 500+ emails each morning.

People don’t like things that crash.

I did not enjoy working on high bugs because I am a terrible tester and it would take me a very long time to reproduce many of these errors. However I do like the fact that my ToDo list is much much shorter than it used to be.

Frustration: how do you reproduce something that is not supposed to happen? Relief: our big red bug count on the dashboard is not a number divisible by 100.

Why was this milestone important? What did you get out of it?

[We now get] faster detection of new bugs.

The product has become much more stable as a result of our focus on the bug hunt, and I think this will lay the groundwork for future required levels of excellence. Before, each new high bug was a drop in the bucket. Now it will be more like a gong at a funeral procession.

The code is much cleaner now, so my OCD isn’t triggered everytime I look at it.

Now that our Critical and High Bug count is approaching zero, the Engineering Team is experiencing a mix of feelings. It’s not that we were particularly attached to these bugs, or we’re going to miss them or anything. It’s more of a fresh, clean start feeling, a blend of nervousness and excitement for what comes next. It’s time to stop looking at old code and start creating new one.

May all those bugs rest in peace.