Manager.io – Free accounting software for small businesses
manager.io
manager.io
I have an error on emailing invoices. It says just "Error" in modal.
I'm curious as to why have you decided to package this as a desktop software, rather than a web app?
Just guessing
Side Note, for those who haven't downloaded the app. There doesn't seem to be a mention for the cloud storage option on the home page. The app stores data locally, but offers the option of cloud storage with additional benefits for $5/month. Screenshot: http://i.imgur.com/zWYpv7I.png
And, incidentally, you are welcome for this submission ;)
The people who make this could sell to GoogleAppleSoft, get hit by a bus, or start charging stupid money for it, and I'll still have a copy and all my data. A webapp by a company I've never heard of before needs to do much more to reassure me that won't happen.
I use QuickenPro (or whatever they call it today) and while I dislike it, it has Maximum Accountant InterOperability (MAIO) - since it's what my accountant's office tends to use.
I really like the idea of a simple, straightforward, just enter the data and get stuff done without getting in my way sort of package, but without AIO and preferably MAIO, I ain't even thinkin' 'bout thinkin' 'bout switchin'.
I suspect I'm not the only one in this boat, and "I dislike that other thing" doesn't really make "the other thing" broken - and if it ain't broke, why fix it? (In other words, the pain of sacrificing MAIO likely exceeds any pain from using "the other thing".)
What plans, if any, do you have for data import/export to ease pain and ensure MAIO?
A couple of questions:
How do I set up things like financial year start date, VAT quarters, etc.
Does manager.io support flat rate VAT? (I'm in the UK)
Not that it matters, I'm just intrigued - why is the OSX package so much bigger?
2.) There is no need to setup financial periods, just setup individual reports for periods you need.
3.) OSX package is bigger because it bundles Mono dependency.
In the flat rate VAT scheme I pay 14% of my turnover, instead of [VAT on invoices] - [VAT on purchases], this saves me a bit of money, but there's not much software that supports it.
Any chance you'd develop a generic VAT plugin? The requirements across Europe must be quite similar apart from rates, periods and invoice/receipts based calculation. I ask, because I doubt there'll be much impetus for you to develop an Irish VAT plugin, given the size of our population and there's no point in even trialling the software without it.
I created a request on your uservoice page, for what it's worth: http://manager.uservoice.com/forums/202564-plugin-ideas/sugg...
- Regulation: Some countries (and some US States) do have guidelines on how this type of software must be constructed, make sure you are compliant to those regulations if it's the case. Example: IIRC you need permits to even start building a POS solutions in some states.
- Integration: An usable accounting software must include HR or have integration with common HR software used by most companies. HR is one of the most complex parts of accounting. Most clients will have outdated solutions they are comfortable working with and won't change completely to your software, make sure you can integrate with tools they want to continue using. Only fight the old if the option you are offering means task elimination. Don't forget you need to integrate with banks, but that's easy.
- Customization: Human systems are not pretty. There are things that do not make sense to accounting and are often loaded with emotional decisions, human relationships and corporate strategy. Sometimes a software just streamlines the human mess, make sure your software can be customized by your clients to a certain point.
Have you thought on maybe making a walkthrough screencast for tech guys like us from zero to doing the whole accounting through your app?
Thanks for the app, great job :)
Nope. Customer lost.
Look, I hate Quickbooks and Quickbooks Online. I really, really do, but I will not use a financial product that doesn't connect to my financial institutions. Period.
Do you want to know what MY startup dream is? I want someone to give me money, and then I want to go create a service that kicks the crap out of Yodlee and Intuit's own bank connection system. I want it to use REST APIs when it can, OFX when it should, and intelligent screen scraping when it must.
I want to build a startup based on an open core of specifications for how to connect to every financial system in the world. I want that spec to be executable and available as a simple library with bindings to every language you can think of. If you have a new institution or your bank changes and you can fix it, I want you to be able to fork the library and send us a pull request.
I want end users to be able to go through a "guided login process". "OK, log in now", "OK, click on the accounts list", "OK click on a transaction". "You're done! We've autogenerated a basic scraper for your bank. Thanks for helping us out."
I want to make money off this library by providing a simple, unified REST API behind all this mess that provides the computational resources to handle millions of customers connecting with thousands of institutions.
I want this company to provide push notifications so your app can do clever things when people spend money.
I don't want you to have to sign an NDA and pay thousands of dollars just to get permission to play with it.
I want it to be the Twilio of Banks.
But if you want to take the code and go your own way, you can.
I really don't know why we've let just a few companies keep our collective financial data locked up for so long. Is it because it's so expensive to get it working? Well why not spend it on people who will create an open, scalable system that can still make money?
Instead, we have Mint.com and mvelopes. That's it, really. Have an idea for a personal finance tool that lets you create "virtual subaccounts" for your checking and savings accounts so you can leverage double-entry bookkeeping in your personal finances through a clear metaphor? Great! Now have fun spending 10 minutes every two days copying and pasting stuff from 10 websites into 1.
It's just madness.
You know that "one weird thing" you're passionate about that's not really related to anything else you're passionate about? This is it for me.
P.S.: lubos - this isn't really about you or manager.io. I commend you for making something and getting it out there. This is about the thing that makes every one of these attempts inevitably fail, and it's sad that we're all being held hostage to crappy software because of it. I wish you success, I hope that I'm completely wrong.
2) Users don't want to give you their username and password for their bank because they're not complete idiots.
That didn't stop Yodlee or Intuit.
> Users don't want to give you their username and password for their bank
That just isn't true. Millions of people give them out to Mint.com, and that was before it was ever purchased by Intuit.
The banks make it hard. The only good thing is they evolve like molasses, meaning the crawlers don't break often. But the fragility of it all is crazy. There's a reason yodlee charges so much.
Would almost love to see them open source it all. It's such a pain that open source seems like the ideal solution to scaling development of each crawler.
With reference to the rant about importing data directly into one's accounting software of choice, the random nature of bank data formats is more likely to render it impossible, especially for the application developers who I'd say would be weighed down with maintaining the core application.
I think the best option would be for the core accounting application to have a well defined format for import/export, leaving the work of getting data into that format for another application or project like the ones mentioned in other sub-threads here (simplefin.org looks interesting aready).
I currently use a FOSS (I think) Windows application called TurboCash (turbocash.net) which does a pretty good job, but also requires some working to get bank data in. I'm thinking of trying out ledger-cli, with some hack work on getting bank data in. With my recent drive toward the command line, I'm hoping this may be my accounting Valhalla.
It works great for us but something breaks about once or twice a year when one of the 3 banks we interface with changes something, so I can see this being very hard to solve generically in a way that works all of the time for non-programmers.
Still, I would recommend this solution to anyone who is comfortable with Ruby and ALSO comfortable with accounting because ledger is great but it also allows you to shoot yourself in the foot if you don't know what you're doing.
Email in profile.
Shoot me an email at william [at] plaid.io, always love to talk with people passionate about the space.
FWIW, I'd prefer to have automated transaction importing but since I don't, this service actually appeals to me more than the services which tout it has a primary feature.
But I'm curious about a few architectural decisions. What made you to decide to build each HTML page by hand?
Code like this[1] makes my eyes bleed... reminds me of the faux-OOP HTML builder classes that used to be a fad among PHP programmers (or ISAPI & Delphi web developers of old) a while ago.. No offence, but much of your Manager.HttpHandlers.* codebase feels like messy, ugly PHP4 code ported to C#...
What made you decide against template-based output rendering (Razor, NVelocity, NHaml, .liquid to name a few)? With template-generated output, the business logic layer could be decoupled from the UI. I had only a cursory glance at your code (and thus could be wrong), but it seems manager.io's DAL/BLL layer is intermingled within the GUI parts.
The protobuf DLL was named protobufnet.dll in the MSI. But the proper filename should be protobuf-net.dll
I think user input validation and error handling could be made more robust.
Additionally, spawning 5 HTTP worker threads to serve a single user seems a little overkill.
These are few of the issues I've noticed during the 5 minute tinkering with your assemblies. But don't let this critique discourage you. The app looks good - I guess end users won't care how it's built so long as it provides real value...
PS: Thanks for the heads up about Eto forms! I'll give it a spin and see how it fares against Xamarin's XWT.
Love it. Recommended.
I've downloaded OP's application and whilst it seems much more straight-forward, I've come across a problem with transfers between accounts that makes me feel that it isn't quite ready yet.
Looks like I might have to settle for GNUCash.
I can't believe how difficult it's been to find a solution for simple double-entry accounting that's also self-contained (ie, I can create invoices and attach receipts). Our side project doesn't make enough money to justify spending on Quickbooks or a monthly site subscription, but I'm not convinced that they would be the right answer, anyway.
Though it is an ERP, you can just use the accounting and sales modules and hide the rest.
(I am a developer at erpnext)
System.FormatException: Guid should contain 32 digits with 4 dashes (xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx). at System.Guid.GuidResult.SetFailure(ParseFailureKind failure, String failureMessageID, Object failureMessageFormatArgument, String failureArgumentName, Exception innerException) at System.Guid.TryParseGuidWithNoStyle(String guidString, GuidResult& result) at System.Guid.TryParseGuid(String g, GuidStyles flags, GuidResult& result) at System.Guid..ctor(String g) at Manager.Objects.Get(String entityId) at Manager.HttpHandlers.File.Upgrade.Get() at HttpFramework.HttpModule.ProcessRequest(HttpRequest request) at Manager.HttpModule.ProcessRequest(HttpRequest request)
curious to understand your technology choice
Would it be possible to use other languages with Eto?
I have a tech related question. It seems like you are running a web server locally and using a web browser component to display the pages processed locally.
Would you care to explain how everything is setup?
What webserver are you using?
Is it a QA app with a webview?
Thanks!
One question, can bank accounts be linked for realtime importing or is it based on importing csv's only etc?
I am looking for alternatives though.
1. It's free (how does the company backing it plan to stay in business?).
2. It's free (as in beer), so I/the community cannot take over in case the product/company ever goes under.
Thanks for your work.
I'd also suggest you create a bitbucket account for issue submission since:
1. You can enable access only to issue tickets 2. you can keep your source code private 3. it's got a low barrier to entry (you don't actually need to keep source code there, but git is awesome and so is bitbucket)
I'm sure that any small business package is going to have a chart of accounts, invoice creation, etc. What I have to make sure of is that my accountant can import the package's exports and do my taxes. :)
Looking forward to taking it for a test drive.