My company wants to purchase new software for our General Ledger. We want to be able to interface it with various other sytems, all purchased. Nothing is custom built. The software our Accountants like does not have any APIs. However it does allow for imports and exports through various file formats.

The imports (which are most import to us) can be triggered by an import file being placed in a folder. A "steering committee" that is involved in this purchasing decision is made up of people who are not either IT people or programmers. They're lawyers, a chief executives, a compliance officer and a few others in similar roles. They are fixated on this software having an API, or APIs, I don't which is more proper.

It seems to me that with the import and export functionality we can do what we need to do. Since we don't write our own software we couldn't code to an API. But, I don't have enough experience to really know what an API might offer that the software in question couldn't deliver. I chair the steering committee and would like us not to get side tracked by something that I suspect is irrelevant. Can anyone help me to understand what I might be missing, or rather how an API would be advantageous?

  • 3
    Semantically speaking dropping stuff into a folder that is automatically read is an API. It's a Point where the Application is Interfacing.
    – user28988
    Feb 13 '13 at 2:14
  • 1
    Do you know what API means very clearly? Are you a software engineer? How pointy is your hair? Manager pointy? Directory pointy? C*O pointy (gads!)? The file mechanism is an API in every sense of the word, and can be used for interfacing with outside applications. There's no real advantages to the "API" your referring to unless they explicitly mean a web-based interface which would need to be built separate to work with the file-dropping mechanism. Feb 13 '13 at 4:21
  • @World Engineer The P in API does mean "point" it means "Programming". Dropping files into a folder is not programming. The I in API does means interfacing as in contact, it means interface as in abstraction.
    – rism
    Feb 13 '13 at 6:54
  • 1
    The discussion of an API is not irrelevant but rather a key consideration. What you need to be doing (IMHO) is asking your committee how an API on GL module would be advantageous to your company. You might be right and it could be meaningless but without knowing anything about your business it's difficult to offer any advantages since you seem so adament that no prog. will be done / is required. If this is the case then obviously an API is not neccessary but... is that the case? Draw a flow chart of how your modules interact, if thats somehow hands free then you dont need an API... yet.
    – rism
    Feb 13 '13 at 7:25
  • No, I'm definitely not a software engineer. I've been writing programs since the 60's, but always one-off, for single purposes. I really appreciate the info/opinions. Oh, my hair is almost non existent, although I appreciate the reference. Feb 13 '13 at 12:36

API = Standardisation (to a much larger extent than text files)

Having spent a couple of years developing an application that a particular client wanted to interact with MYOB I would seriously recommend a GL with API.

Text file import/ export is an horrendous way to run a company.

(IF) you ever need any customisation of the product/module the first thing any developer is going to do is build some kind of API if you dont already have one. Then 6 months later, she is unfortunately killed in a car accident... and you need some more customisation. So the next developer looks at the scratch of an API started by the first and then modifies/appends to that for the purpose at hand... and so on.. and before long you have a frankenstein on your hands.... because as you say you dont develop in house and whose to say any of these developers are experts in the GL module anyway. So they start creating their own API's according to what they think is the GL module, not neccessarily what it actually is.

Whereas a product with a prebuilt API is straight form the horses mouth. The people who built the GL module are saying this is how you should interact with our product programmatically. Then you can go out and get a developer who actually already knows the API.... from that last job they did. i.e. they dont have to learn your company's frankenstein first.

Also with a pre built API, add on modules/upgrades etc from 3rd party vendors become more feasible. Again because the GL's API is standardised and known outside of your company and therefore represents a market opportunity to hungry developers.

Security: With an API you can more securely communicate with your GL. It's much harder to hack a systems process memory to mess with GL API based imports/exports, than it is to open and modify a bunch of text files sitting in some folder on the file system.

Your argument seems to be we dont need programmatic access to the product and we never will, well good luck with that. ;)

If you've recently under taken a full strategic review of how IT is used in your company and can honestly say they you will never need to modify either how you get data into your GL and how you shape data coming out of your GL then go ahead and by pass the requirement for a new GL module to have an API.

That said the future is the great unknown. I personally would NEVER recommend a GL module without an API.... simply because I know whats out there.... and no accounting package that I'd be looking at for our customers (SME's) going forward is without an API.... especially given the uptake on cloud computing.

  • Thank you very much for the info. We just don't have the staff to build in house, we would out source for that. Also, more as a corporate direction we decided some years ago to buy rather than build, when possible. Of course things always change. I certainly wouldn't say we'll never need programatic access to the GL. However for the near future we really don't have the resources (including in Accounting) to do much more than transfer data to and from it. We currently do that manually, so even transferring data is a big leap ahead for us. Feb 13 '13 at 12:41

Trained Software Engineer in a debate/discussion/argument with Lawyers, Accountants and CEO's - you will lose, no doubt about it! The only way out for you is to have appropriate levels of CYA documentation....

Seriously - you cannot use facts and numbers against this emotional attachment to an idea/ideal. If they have read an magazine saying "It must have an API", then they will say "We need an API", and will not be happy without one. They will have absolutely no idea what one is - this is your biggest asset, use it.

What I would do (before / apart from giving up and writing a stack of CYA emails), is discuss the file import/export as an API, and always use the word "API" when discussing it. This will move the focus onto functional requirements and how it can achieve what needs to be done, and away from the "I must have an API" dance.

  • He's not a software engineer (unless I'm mistaken) Feb 13 '13 at 4:22
  • Jimmy, you are correct. In a sense I'm not trying to "win", I just don't want us to reject a good accounting product that otherwise fits well with our company if there's not a sensible reason for it. Clearly I don't know very much about how APIs can be used, nor as previously pointed out what makes something an API. I greatly appreciate all of the comments and opinions I gotten. Feb 13 '13 at 12:44
  • @MitchellKaplan - The only way to know if the product will meet your requirements is to trial the software. Ask the company for a 90 day paid trial, if the software meets your requirements, use the 90 day period as a down payment towards the total cost of the software.
    – Ramhound
    Feb 13 '13 at 14:15

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.