Ask HN: What about accounting software?

10 points by viandante ↗ HN
Hello,

It seems I am a finance/controller guy with passion for programming. In my job, we deal with a huge amount of data coming from many different places, usually in excel spreadsheets. It is painful and it leads to error (in a field where errors kill your reputation).

The mainstream software used is called "Hyperion". While this is good for submitting to corporate, still most of the calculation and consolidation (imagine consolidating numbers in excel from 30 entities around the globe) happen in excel. Which, I think, is an outdated tool for this kind of things.

This problem (handling and consolidating data in finance) is HUGE. It leads to big productivity problems and it is one of the main reasons people have to work late. Solving this, would improve quality of life and make some money..

And so my question, do you know of any people/group or project in the area of accounting/finance in order to improve data handling and consolidating? I have a lot of 'field' knowledge and ideas I'd like to discuss. This could be a lot of fun.

9 comments

[ 2.7 ms ] story [ 35.6 ms ] thread
I've done quite a bit of work with Hyperion - mostly by building a replacement reporting engine (which, I have to say, is wildly better than Hyperion's own report generator).

I've done a fair amount of thinking about building a "better Hyperion" - but as I don't have an accounting background I've never progressed it very far.

Do you have some code of the report engine? I'd love to see it.

For the accounting knowledge. I don't think that is the point. The point is more what accounting people need and how they think. Most of the accounting could be done with R or numpy or things like that, but that would scare the hell out of any 'normal' finance guy...

The code is owned my employer!

My point about not personally having the relevant accounting expertise was more about having the credibility to sell such a tool - not building it.

About the credibility. Hyperion (especially mixed with citrix) is not that reliable and still is a reference in the field. I wouldn't think credibility is the main issue, at least not as much as usability and productivity (which I think are quite difficult to match).
I meant my own personal credibility! :-)
In another life, I was a specialized type of accountant, for a while. I used to -- unofficially, at my own initiative -- save my pure accounting co-workers days of time and effort by e.g. taking 15 minutes two write up a quick bit of Excel formulation and/or scripting.

(Lest this sound dangerously hackish, I was a stickler for accuracy and often greatly decreased their error rate in the process including through describing how to better manage their task and errors.)

These were the front line workers; the people who actually "do stuff".

I was appreciated by management, to a point. Above that point, though, it became a matter of politics and connections.

At that level, people "bought what they had connections to". Which was subsequently foisted onto those "front line" workers. I remember, for example, interfacing an SAP system radically different from its predecessor, into our own systems. No one asked my opinion; the "new way" just came "thrown over the wall".

That's what you're up against. A great degree of not "what you have" but "who you know".

Those coworkers of mine lucked out, in a small way, because they knew me. The corporation was happy to leave them toiling at their "digital loom piece work", until it shipped their jobs off wholesale to elsewhere, because that looked better on the quarterly bottom line.

A lot of the "big" financial software I saw was similar. "The professionals" came up with "the way" (often rather bastardized, due to their own internal process) one should do things, and sold packages that purported to more or less do that. And you were stuck with that. There was great pressure to adapt your process to the purchased system, rather than vise versa.

On the "front end", people had to come up with work-arounds to make that system do enough to let them manage the reality on their desks.

A lot of accountants make a glorious, tragic mess of Excel. I've seen it -- over and over and over, again. But the big systems are seldom a solution, in good part because rather than looking at those people's problems, they impose a top-down methodology that nobody really wants and that makes a lot of work in and of its own nature. Feed the beast, rather than taming it.

=== A lot of accountants make a glorious, tragic mess of Excel. I've seen it -- over and over and over, again. But the big systems are seldom a solution, in good part because rather than looking at those people's problems, they impose a top-down methodology that nobody really wants and that makes a lot of work in and of its own nature. Feed the beast, rather than taming it. ===

And in fact the point is more on a substitution/integration of spreadsheets, than a shiny new system.

To be fair, I understand all what you say. I just disagree a bit on the new systems. I use SAP, cognos and hyperion and they suck not because they are new or badly implemented, but because they are closed and the csv they output is amazingly horrible. Also, those tools don't seem to have a decent api accessible from decent programming languages, so welcome clicking hell and goodbye automation.

If those tools where open source, at least you could hope in some kind of improvement or at least integration with your own way of working.

---

On the carrier side. Let's just say I don't do this for the carrier (I would like to consult on this things and leave corporate job). But automating, even at a simple level, tends to improve my output and reduce error, which is a huge advantage over the other employees that have to stay late because their look ups formulas are too heavy and files take 10 min to save or 'calculate' stuff.

While I don't know of any specific projects, I have dealt with the problem myself. I can't tell you how many operations applications tried to integrate with BMS, or mapping data from disparate subsidiary systems during an SAP implementation.

At first glance, I think there is probably something to the idea of modular mapping between popular systems. The idea of disrupting the service providers that "assist" with software transitions for huge dollars is compelling. However, if I understand what you are saying, GL mapping is a tedious process that requires both extensive understanding of financial statements (generally) and specific knowledge of the company's current practices (especially if they are public).

Methinks the real value is in automating the mapping, but there is just no way that could happen, without spending just as much time double checking the logic...which means they could have done it manually. IDK...

Best of luck. Go make a 100 million on the idea and prove me wrong :)

First, I am not thinking money right now, I am much more interested in solving my issue. Yesterday I spent the whole day loading a bunch of filed in hyperion. With a good script that takes 10 seconds.

Second, accounting does have a logic (GAAP...). In fact, hyperion does make money, even being a horrible tool (not web based, it is used with citrix, you can imagine...).

Third, the main problem of all this software that 'assists', as you say, is that it invents csv formats and standards every time. Leaving you no choice but using GUIs that when it comes to generate a lot of reports slow you down a lot (think of SAP that doesn't have an easy way to script things).

Fourth, Excel is not a database. And not being a database, you lose all the SQL operations. No group by, sum, order, where, and stuff. Yes you have pivot tables, but you can't perform a join and you can't use big datasets with them.

Fifth, in accounting working vertically on the dataset is not enough. You need to perform various 'shaping' operations. You can do this with excel, yes, but again, it is painful.

Sixth, there are for sure better ways of consolidating data from different files. In excel you 'link' different workbooks in a master file. I am even going to tell you why that is a bad practice, I think it speaks for itself.

So, no, it's really not about the mapping. It's about serious technical issues that nobody is taking care of. And I am pretty sure this is because programmers don't dare to think like an accountant.