What is the value in using the “split transaction” feature present in some personal finance management tools?
"Split transactions are indispensable to anybody interested in accurately tracking their spending. If I go to the big-box pharmacy down the road to pick up a prescription and then also grab a loaf of bread and a jug of milk while there, then I'd want to enter the transaction into my software as: I desire entering precise data into the software so that I can rely on the reports it produces. Often, I don't need an exact amount and estimated category totals would have been fine, e.g. to inform budgeting, or compare to a prior period. However, in other cases, the expenses I'm tracking must be tracked accurately because I'd be using the total to claim an income tax deduction (or credit).  Consider how Internet access might be commingled on the same bill with the home's cable TV service.  One is a reasonable business expense and deduction for the work-at-home web developer, whereas the other is a personal non-deductible expense. Were split transaction capability not available, the somewhat unattractive alternatives are: Ignore the category difference and, say, categorize the entire transaction as the larger or more important category.  But, this deliberately introduces error in the tracked data, rendering it useless for cases where the category totals need to be accurate, or, Split the transaction manually. This doesn't introduce error into the tracked data, but suffers another problem: It makes a lot of work. First, one would need to manually enter two (or more) top-level transactions instead of the single one with sub-amounts.  Perhaps not that much more work than if a split were entered. Worse is when it comes time to reconcile:  Now there are two (or more) transactions in the register, but the credit card statement has only one.  Reconciling would require manually adding up those transactions from the register just to confirm the amount on the statement is correct.  Major pain! I'd place split transaction capability near the top of the list of ""must have"" features for any finance management software."
"So... from a business perspective, this way of building a piece of software doesn't make any sense at all. To take their example of a book trading app... how do you parse out the core function vs. the revised specifications adding features. The core function of most apps are dead-nuts simple. For the book trading app, the core functionality is a forum website, such as reddit. The need for an app which allows you to sell it is the value-add of the software, which is all in the features.   Call the ""standard"" way of doing things, from a set specification, a ""top down"" design cycle. Call the ""new"" way of designing a ""bottom up"" design cycle.   So now you have a ""minimum viable product"", which is now subject to all the pain of a top-down design cycle and you are back to where you started. Now, every bottom-up design cycle has a goal and its own minimum viable feature improvement... so you are really back to a progression of top-down design cycles superimposed on bottom-up product feature set evolution.   Making a real product that people use is always going to be a combination of top-down design driven from the business side, who determines the features that customers want (i.e. the minimum viable product), and bottom-up design cycles where engineering has to communicate what is possible to design in a certain time frame. There is always a tension between the forward looking business side which is trying to project what customers want and pushing engineering to schedule their creativity, and the engineering side which is trying to deliver creative product designs on an externally imposed schedule.   This bottom-up design cycle is not unique to software. Where developing software differs from developing hardware is that software allows for this design cycle to be very short and very discrete. Software can be developed in discrete modules and linked together. Hardware is more integrated, thus having longer design cycles, but can still be designed using a minimum viable product with design cycles adding features incrementally. Look at the cell phone/smart phone hardware business for a good case study in this. Yearly design cycles, each design cycle has a minimum viable feature set and some stretch goals, and work on feature sets stop when the clock runs out. But to think that software is magic, should be driven entirely bottom-up, doesn't have some sort of feature map superimposed on the workflow, is to get lost in an idealism. Better to use top-down and bottom-up design cycles as tools to navigate the business." "You can use the 6900 to make an investment.  Or to buy something.  That's why people keep reminding you that you could make interest.  Because most people think of either 7200 now or paying the same 7200 over time.  So you could just be storing the 7200 under the mattress until you pay it out.  Obviously in that case, inflation doesn't matter (""is not applicable"").  You've given up the use of the 7200 from the beginning.   Think of it instead as 7200 now and twenty-three payments of 300 each.  So 14,100 total.  Then you can spend 6900 on something else at the beginning or spend 300 a month on other things.  The difference between spending 6900 now and 300 in each of twenty-three months would be measured in inflation.  Of course, this requires you to have both 7200 now and an income stream producing at least 300 a month.   Another way of doing things is to take 6900 and invest it.  Each month you remove 300 and use it to make a payment.  We're now back to just one 7200, plus the interest over time.  I would argue that this is still an inflation advantage.  It's just that instead of spending the money, you invested it.  And that of course is your prerogative.   The point being that you would not have that opportunity if you paid up front.   Now to calculate the difference in monthly payments of 300 euro using the above webpage what should I do?   As already said, you would have to calculate twenty-three values and then sum them with the 300 you pay up front in the monthly.   There are other ways to calculate it, if you are not using that particular tool.  For example, there are formulas to calculate the net present value of an annuity.  E.g. see Investopedia.   Where: P = the present value of an annuity stream PMT = the dollar amount of each annuity payment r = the inflation rate n = the number of periods in which payments will be made Investopedia talks about interest rates, but you can put inflation there for this purpose.  In that case, r might better be called the ""discount rate"".   PMT is 300. r is whatever estimate you are using for inflation.  E.g. .003 per period. n is 23.   Note that the monthly inflation rate is smaller than the annual rate.  So .003 is about 3.66% annually.  3.04% annually is more like .0025 a month.   I found calculators for this with search terms ""present value of annuity calculator"".  Some of the calculators will take the annual rate (3.66%) and number of periods per year as input.  Or the calculator may take a monthly rate as a percentage (.3%) rather than as a decimal (.003).  So be careful of the inputs.   This gives me a net present value (NPV) of 6,657.69 for the 23 payments of 300, assuming .3%.  Or 6957.69 is the NPV of the monthly payments and 7200 is the NPV of the 7200 up front.   Obviously if you can pay less than 6957.69 up front rather than 7200, then it makes more sense to pay up front.   Even without a discount though, it still may make more sense to pay up front.   How much those intangibles are worth is up to you." "Before the internet, there were these things called ""BBSes"". Bulletin Board System. They were usually privately operated, the software ran on a single personal computer, and most of the time they had 1 phone line connected to them. There were thousands of these systems in every state.  Visitors would call the BBS phone number and connect in a 1 to 1 conversation. The user would then be presented with all sorts of menus and interactive experiences, usually with ANSI colored text. The primary feature of any BBS was the forum, called a Bulletin Board at the time. But many BBSes also had other things. File sharing sections, games, etc. Basically everything that the larger internet is used for today.  Possibly the worst thing that happened to the Internet was the dot com boom. As a result of a tiny few people getting filthy rich, it has created a different landscape where large corporations are kings and it's very difficult for smaller community projects to find the sort of success they would otherwise enjoy.  If the internet were not so ruled by media giants like Google and Facebook, you would see a lot more smaller sites and communities, similar to the BBSes of old. They would have more personality and the experience would probably be ""better"".  So no, Soundcloud doesn't matter that much. Soundcloud started as a small website, and they deserve to exist as much as anyone, but every time a media giant on the internet collapses, we see dozens of small startups take it's place, and the result is often ""better"".  There is definitely value in having a central repository, I wonder if something like Soundcloud could exist decentralized. A lot of smaller music sites with preview and purchase features that form a sort of meta-network." Mint.com is a fantastic free personal finance software that can assist you with managing your money, planning budgets and setting financial goals. I've found the features to be more than adequate with keeping me informed of my financial situation. The advantage with Mint over Microsoft Money is that all of your debit/credit transactions are automatically imported and categorized (imperfectly but good enough). Mint is capable of handling bank accounts, credit card accounts, loans, and assets (such as cars, houses, etc). The downsides are: "Bookkeeping and double-entry accounting is really designed for tracking the finances of a single entity. It sounds like you're trying to use it to keep multiple entities' information, which may somewhat work but isn't really going to be the easiest to understand. Here's a few approaches: In this approach, the books are entirely from your perspective. So, if you're holding onto money that ""really"" belongs to your kids, then what you've done is you're taking a loan from them. This means that you should record it as a liability on your books. If you received $300, of which $100 was actually yours, $100 belongs to Kid #1 (and thus is a loan from him), and $100 belongs to Kid #2 (and thus is a loan from her), you'd record it just that way. Note that you only received $100 of income, since that's the only money that's ""yours"", and the other $200 you're only holding on behalf of your kids. When you give the money to your kids or spend it on their behalf, then you debit the liability accordingly and credit the Petty Cash or other account you spent it from. If you wanted to do this in excruciating detail, then your kids could each have their own set of books, in which they would see a transfer from their own Income:Garage Sale account into their Assets:Held by Parents account. For this, you just apportion each of your asset accounts into subaccounts tracking how much money each of you has in it. This lets you treat the whole family as one single entity, sharing in the income, expenses, etc. It lets you see the whole pool of money as being the family's, but also lets you track internally some value of assets for each person. Whenever you spend money you need to record which subaccount it came from, and it could be more challenging if you actually need to record income or expenses separately per person (for some sort of tax reasons, say) unless you also break up each Income and Expense account per person as well. (In which case, it may be easier just to have each person keep their entirely separate set of books.) I don't see a whole lot of advantages, but I'll mention it because you suggested using equity accounts. Equity is designed for tracking how much ""capital"" each ""investor"" contributes to the entity, and for tracking a household it can be hard for that to make a lot of sense, though I suppose it can be done. From a math perspective, Equity is treated exactly like Liabilities in the accounting equation, so you could end up using it a lot like in my Approach #1, where Equity represents how much you owe each of the kids. But in that case, I'd find it simpler to just go ahead and treat them as Liabilities. But if it makes you feel better to just use the word Equity rather than Liability, to represent that the kids are ""investing"" in the household or the like, go right ahead. If you're going to look at the books from your perspective and the kids as investing in it, the transaction would look like this: And it's really all handled in the same way an Approach #1. If on the other hand, you really want the books to represent ""the family"", then you'd need to have the family's books really look more like a partnership. This is getting a bit out of my league, but I'd imagine it'd be something like this: That is to say, the family make the sale, and has the money, and the ""shareholders"" could see it as such, but don't have any obvious direct claim to the money since there hasn't been a distribution to them yet. Any assets would just be assumed to be split three ways, if it's an equal partnership. Then, when being spent, the entity would have an Expense transaction of ""Dividend"" or the like, where it distributes the money to the shareholders so that they could do something with it. Alternatively, you'd just have the capital be contributed, And then any ""income"" would have to be handled on the individual books of the ""investors"" involved, as it would represent that they make the money, and then contributed it to the ""family books"". This approach seems much more complicated than I'd want to do myself, though." Under US law, if you clearly have more than half of a torn bill it is worth its full value; the smaller piece is worth nothing... except that having both halves makes the banking system much happier, since it prevents some particularly stupid counterfeiting attempts. So this proposal wouldn't be cheat-proof unless the cut is close enough to the middle to make determining 51% difficult. And I'd like to see you try to explain to a bank how so many bills were cut in half... (This is more normally an issue when money has been damaged unintentionally, of course.) You're trying to mitigate the risk of having your investments wiped out by fraud committed by your broker by using margin loans to buy stock secured by other, non-cash assets in your account. The solution that you are proposing does not make any sense at all. You mitigate a very low probability/high impact risk by doing something that comes with a high probability/medium impact risk.  In addition to interest costs, holding stocks on margin subjects you to the very real risk of being forced to sell assets at inopportune times to meet margin calls. Given the volatility that the markets are experiencing in 2011, there is a high risk that some irrational decision in Greece could wipe you out. If I were worried about this, I would: If you have enough money that SIPC protection limits are an issue, you desperately need a financial adviser. Do not implement any strategy involving margin loans until you talk to a qualified adviser. Yup. What I wanted to know was where they are pulling it up from. Have casually used Google finance for personal investments, but they suck at corp actions. Not sure if they provide free APIs, but that would probably suck too! :D