Importing Stripe Transactions into Xero

About a year ago, Paul wrote about the trials and tribulations of using PayPal. There is a lot to not like about PayPal, though most of my criticisms result from doing the bookkeeping for a company that posts a lot of PayPal transactions. Around the time he was writing, Stripe came to Canada, and we cheered (“Hurrrrah!”), because it meant we had another option. A newer option. An option whose UI might be almost navigable! Paul signed up, delighted in Stripe’s really snazzy documentation, and started writing a front end for us to send invoices that clients could pay by credit card, using Stripe.

At our accountant’s suggestion, we use Xero for our bookkeeping at WonderProxy, and, for the most part, we’re happy with it. Xero can automatically import statements from your bank accounts (including your PayPal account, which is important for us), track accounts payable and receivable, and track transfers between accounts seamlessly. Like I said, we’re mostly happy with it: it has trouble with one of our credit cards, so I have to manually import its statements, which is a bummer, but what can you do? Customer support has always been prompt and, while they’ve sometimes been unable to fix the problem, have at least explained what’s happening and suggested workarounds. It’s satisfactory… and our accountant likes them, so y’know, that seems like a good thing too.

When we started using Stripe, Paul and Will wrote their own front end to manage payments. It’s really easy to use, and has made invoicing customers a genuine pleasure, especially when I think about creating PayPal invoices. It’s another bit of functionality that we’re really happy with. At the time, we didn’t really think about how to get all the Stripe activity correctly represented in Xero. I didn’t actually bother to tackle the problem until our financial year ended and it was time to deal with taxes. Xero supports Stripe as one of its payment processors for its built-in invoicing service, but we don’t use that, and I couldn’t figure out how to make Xero automagically figure out our Stripe transactions otherwise.

Armed with the knowledge that only tracking Stripe’s transfers to our bank account was Bad Accounting, I set out to import our Stripe transactions and properly reconcile them against the transfers to our bank account. If anyone is trying to do the same in Xero, this will hopefully help.

  1. Create a new bank account for your Stripe transactions. From the Accounts tab, choose Add Bank Account. I chose the Bank Account account type. It’s probably the most accurate representation of what Stripe is, given the options.
  2. Log into Stripe, and download all your transactions as a CSV. Save them as something meaningful, like “Stripe Transactions Date-Range”
  3. Still logged into Stripe, navigate to the bank transfers, and download all the bank transfers. You’re going to match these against the statement lines in your bank account, so that everything matches up nicely. Save them as something meaningful, like “Stripe Transfers Date-Range”.
  4. If you reconciled the transfers from Stripe to your bank account (like I stupidly did), you need to un-reconcile all of them. This is a pain, but necessary. Do that now.
  5. Create CSV subfiles.First, Xero doesn’t understand Stripe’s time format. Awesome, eh? So, you need to remove the time portion of the date-time field. I did this in TextMate with a really long cursor so I could delete it all at once. You could also create another column and do some magic in Excel, selecting only the yyyy-mm-dd portion of the original column. Make sure you do this for both the transactions and the transfers.Second, Stripe’s CSV output doesn’t deal with fees and refunds in a way that Xero understands. You need to pick the columns that Xero will actually need and create new CSV files:
    • a “Payments” file that includes the ‘Created’, ‘Description’ and ‘Amount’ columns,
    • a “Refunds” file that includes ‘Created’, ‘Description’, and ‘Amount Refunded’ for any refunds, and
    • a “Fees” file that includes ‘Created’, ‘Description’, and ‘Fee’.

    For some reason, Xero likes the first column to be the date column, so putting ‘Created’ first is important.

  6. Import your appropriately-formatted CSV files into Xero. Reconcile. Rejoice!

It’s a weirdly complicated process, since Stripe’s CSV dump isn’t formatted in an immediately usable way. I’m curious about how Xero deals with Stripe transactions that result from its invoicing service. Perhaps there’s something brilliant that I’m missing. Nevertheless, I’m happy that this way, we account for the full amount our customers pay us, the fees we pay Stripe, and the amount netted, which is transferred to our bank account. I’m planning to do the Stripe import (manually) once a month, so it’s not too onerous. If I’m particularly fancy, perhaps I’ll write something to automate it for me… probably not though.

Breaking the Silos

An exciting thing happened at MongoDB Inc. today. For about fifteen minutes mid-afternoon, a diverse smattering of MongoDBers converged on our cafeteria: sales people, HR, marketing, and engineers stood shoulder to shoulder, chatting and commiserating. I learned one of my coworkers used to work at an amusement park, heard some hilarious stories from the marketing department, and laughed along as we misheard an engineer talking about his DOM (document-object model).

Dippin Dots

Omnomnom. Rocky road Dippin’ Dots.

What prompted this convergence? Last week, the lovely person who sits across from me got it into her head that she wanted Dippin’ Dots, so she ordered 35 servings to be delivered (packed with dry ice) to the office. It apparently takes a week, and they arrived mid-afternoon. It seems that all it takes to bring a group of people together is the prospect of unexpected astronaut ice cream.

Companies sometimes put a great deal of effort into getting their employees to talk to each other: the all hands meeting phenomenon is probably a good example.  On a smaller scale, maybe all it takes to get more people talking to each other is a random treat in the middle of the afternoon, unexpected and unplanned. Bonus points if it’s food you’ve not eaten since you were a kid at an amusement park.

 

Learning Emacs

For the past few weeks, on top of writing delightful documentation and exploring New York, I have been executing an herculean undertaking: learning Emacs.

10gen’s lead tech writer is an avid Emacs user: he uses Emacs for his email, his chat client, and, of course, for editing the docs. We write MongoDB’s docs in Docutils, and (mostly) easy to write. It helps to have a text editor that will do reStructuredText syntax highlighting, though, and those seem to be rare. My beloved Coda 2 does not appear to do it; Sublime Text’s highlighting is inconsistent, and its tabs a pain in the ass. TextMate is great, but even it sometimes fills me with rage with auto-indent behaviours that I can’t figure out / turn off.

So my colleague suggested I try out Emacs. It was lateish on a Tuesday afternoon, and I said “why not!” and promptly downloaded the GUI version of Emacs. He kindly gave me his Emacs configuration file so that I would have all his handy reStructuredText-facilitating extensions, and gave me a quick crash course. I suspect part of his enthusiasm was the prospect of being able to use Emacs on my computer when I needed his help with something, but a good deed is a good deed regardless. After a 45-minute pep talk, I was left feeling not unlike I did when my parents bought me my first iMac back in… 1998: “this is very cool, now how the heck do I turn it off?”

Aside: for those of you who do not recall, OS 9 hid the Restart / Sleep / Shutdown menu items in the “Special” menu. The first night I had my iMac, I ended up unplugging the computer in a fit of “oh god what have I done?” and having a cry because of all the money that had been spent on a computer that I had no idea how to use. I bought David Pogue’s “iMac for Dummies,” and life improved immeasurably.

On Wednesday, I remembered that Sacha Chua was an Emacs user, and vaguely recalled her posting a Beginner’s Guide to Emacs. I printed it out, propped it up on my desk, and have been adding to it ever since. Much like the purchase of Pogue’s book, this was an excellent life choice. There are a few things that bug me about Emacs: memorizing keystrokes isn’t something that I’ve ever been very good at, and I don’t like that (given my current configuration) I can’t highlight with shift and the arrow keys. As a learning experience, though, it’s been really pleasant, especially now that I’m starting to remember how to do things (I can now consistently write files, copy & paste, and move to the beginning and ends of lines!).

It sounds goofy, but I’ve always enjoyed the idea of being a person who is good at command line-y text editors. Whenever I see someone mysteriously navigating without a keyboard, typing furiously as windows pop up and disappear, I think it’s neat. Admitting this is both amusing and embarrassing: I’m forcing myself to learn Emacs because I think it looks cool.

Despite my somewhat goofy reasoning, Emacs is kind of fun! At a minimum, it’s made me realize that the way I’ve always interacted with files is not the only way, and it has made my emacs-loving colleague’s workflow is much less mysterious to me. I also really like that I can create a buffer that will execute a command for me: I like being able to generate the html version of whatever I’m working on and being able to click on links to the file if there’s an error.

If you’re just starting out and have an intense desire to look cool learn emacs, check out Sacha’s guide. I also suggest finding someone who is patient and kind, and willing to help you learn.

NY Perl Mongers

It seems I haven’t blogged since moving to New York to work at 10gen, three months ago. I guess all my writing hours have been going towards writing MongoDB’s ever-improving documentation.  Now that things are quieting down a bit, and I am only semi-weekly embroiled in a well of git/docs build-enduced despair, I’m pleased to be getting back into the swing of things.

Last night, the New York Perl Mongers meetup took place in our offices. Mike Friedman, one of my coworkers who works on MongoDB’s Perl driver, among other things, spoke about the Perl API, which apparently allows you to use C to do stuff for you more quickly, and Damian Conway gave an excellent talk on giving better presentations. While Mike is lovely, I probably wouldn’t have attended just to hear his talk – I know very little about Perl and less about C – but some of my coworkers had heard Damian speak previously at OSCON and highly recommended we attend, so attend I did.  Both Mike and Damian were fantastic speakers, and I learned a lot from both… I’m not about to start writing Perl code (let alone using the Perl API), but I took some notes from both talks, and figured they might be worth sharing.

Mike Friedman: Perl API for the Mortally Terrified

“Using C gives you a better appreciation of how powerful dynamic languages are.”

I must admit that this talk went well over my head: not knowing much of anything about Perl, other than that it was another programming language in the family of Python and Ruby and such, I certainly missed some of the more nuanced points. Nevertheless, Mike listed a number of reasons why the Perl API might be something you should look into, which boiled down to:

  • you can make things faster by writing bits of your program in C
  • the Perl API lets you work with the myriad of C libraries that people have already helpfully written
  • the Perl API  lets you do fancy stuff that would be hard/impossible in Perl

He then spoke about the Perl API itself and how you work with it. I did not take notes on that, but I did draw a very confused thought bubble that said “Why are none of these function names actually meaningful?” If you’re a Perl developer and you’re interested in starting to use the Perl API, Mike suggested you check out Practical C Programming by Steve Oualline and the infamous K&R C Programming Language book… so I suggest that too.

Damian Conway: Instantly Better Presentations”

I had no idea who Damian Conway is. I googled him during the pause between Mike’s talk and his, and it seems he’s a well-known Perl developer, and an extremely well-known speaker. I cannot speak to the first thing, but I can say he is, indeed, an excellent speaker. I like to think that I give a pretty decent presentation – I was always well reviewed when presenting in school, at least – but as a person early on in my career who has (no longer) secret aspirations to speak at conferences and share my knowledges with the world, it seemed like it would behoove me hear what he had to say.

Without diminishing things, I have to say that his tips are not earth shattering. They were, however, incredibly well-packaged and well-delivered, which truly hammered home the need to focus on preparing a talk. His approach to choosing topics is incredibly practical, and he provides a strategy that a stressed, slightly panicked speaker-to-be might follow gratefully. He advocated spending 20 hours of prep time per hour of speaking time, though confessed he usually spends more like 100 hours. So that’s certainly something to think about.

According to Damian, being a good presenter boils down to 7 things:

  1. Talk about what you know and are passionate about. If you’re passionate, other people will listen, even if they don’t care about what you’re talking about
  2. Tell a story – either historical, procedural, or anecdotal. This helps to ground the talk and make sure it has good flow
  3. Don’t search for topics: select them. This was a big one for me – Damian advocates writing down everything you can think of about a topic on a piece of paper. A big ol’ brainstorm. Then when you’re ready to figure out what to talk about, you can winnow it down to the core topics
  4. Less decoration, more focus. Almost all of Damian’s slides had five or fewer words on them, in a nice large, easy-to-read font, with a plain background. No extra junk. Slides should emphasize what you’re saying, not distract your audience.

    “The use of a laser pointer will convert your primate audience to a feline audience.”

  5. Manage questions. Appear keen to take them, but make sure they happen when you want them to happen.
  6. Animate code demos. This one was pretty cool. Damian went through some elaborate Perl grammar thing and it made complete sense to me while he was explaining it. The parser tree was revealed incrementally, and then the groups in the tree moved around to map to their equivalent code blocks, and it was very cool. For normal code presentation though, simply highlighting segments as you go through is a great way to keep people from getting confused or lost in your explanation. This was the highlight for me.
  7. Harness your anxiety. I’m not a terribly nervous speaker, but I am a worrier, so this one resonated. Funnelling one’s anxiety and nervous feelings towards productive ones is, apparently, as simple as telling yourself over and over that the feeling of terror is actually a feeling of excitement. Eventually, he says, you’ll start to believe it, and your anxiety will overflow as enthusiasm and audiences will love you forever.

Damian provided the link to his talk’s handout, which you can find at damian.conway.org/IBP.pdf. I highly recommend it, and if you have the chance to see him speak, I would jump at it.

Follow interesting people – read interesting things!

I realized a few weeks ago that my twitter feed was populated mostly by people who I see on the regular: friends from school, my boyfriend, some of his friends, etc. I had somehow created a Google bubble around my tweets. Twitter is a great place to read about cool new things, but the cool things that interest me (ux/ui stuff, information architecture stuff, writing stuff) weren’t making it onto my feed.  I didn’t know who to follow, and I didn’t know how to change that.

I was lucky enough to snag a ticket for Brooklyn Beta last year, and I remembered that there was a page on their site that listed the twitter profiles of all of the attendees. A bit of googling and searching through my email archive revealed it.  There were a few hundred attendees, so I searched for people mentioning UX, UI, and Information Architecture, and found a slew of interesting people, some of whom I followed.

Mandy Brown in particular has transformed me into a bit of a fangirl… a very polite, uncreepy fangirl. She posts incredibly interesting links, seems to be doing fantastic work, and was an inspirational speaker when I saw her at Brooklyn Beta. I’ve not yet figured out how to express “I want to be her when I grow up” as an adult, but that is the feeling I have.

Following smart, interesting people has resulted in me reading a ton of smart, interesting articles. I’m not sure why this surprised me, but it did. As I venture out of academia and into professional life, my twitter feed has grown in importance as a tool for keeping abreast of new tools, trends, and issues, and is a way to keep learning outside of school.

Evernote knows my bank password…

Lately, I’ve been installing a lot of browser extensions: I’m doing a project that involves analysing a bunch of web clipping / sharing apps, so I’ve been dutifully installing the browser extensions that they provide. What’s been striking me, though, is how little we know about the browser extensions we install. I use Google Chrome for most of my browsing—when I went to install the Evernote Web Clipper, this is the message that popped up:

Evernote Web Clipper install message

This struck me as a somewhat far-reaching request: my browsing history and my data for all websites is a lot of data for a tool that is basically supposed to help me copy-paste. “What are they going to do with this information?”, I asked myself, “Why do they need it? Why isn’t there a ‘we have access when you click on the elephant’ clause or something?”.

Initially, I couldn’t figure out how to find out more: I clicked on the “View details” link, and it brought me here… I did a more thorough search once I decided to write this post, and eventually found a link to this:

Google Chrome extension permission explanation

So… that’s something…

I’m not writing this because I think that the Evernote Web Clipper is dodgy… I’m pretty sure it isn’t. I don’t see, however, why an app that I use for saving adorable pictures of owls, newspaper articles that make me happy / angry, and ikea hacks should have access to my banking credentials. I’m sure that there’s a good reason why they request this access… I just don’t know what it is. What I would like to see is an easy way to have these extensions working only when you want them to be working. Yes, I could go into my preferences and enable and disable the extension as I need it, but that is a bit of an onerous solution to what I presume could be reasonably easily implemented.

More than that, though, I wish that people who publish extensions explained why they’re requesting these permissions, what they actually do with the data they have access to, how they store it, etc. I may not mind sharing my data with you… but I do what to know why, and what you’re going to do with it.