How To Assign Payments Received Properly In GnuCash?
"When I receive a check from a customer whom I previously sent an invoice, I go to the customer report for that customer, click on the link ""Invoice"" for that invoice, then click on the Pay Invoice button (very far right side). I then do a customer report and see that there is no balance (meaning all the invoices have been paid). I don't process invoices using the same method you do.  Instead I go to Business -> Customer -> Process Payment.  From there I can select the applicable customer, and a list of unpaid invoices will come up.  I've never experienced the issue you've described. On a related topic: are you posting your invoices?  From experience that has caused issues for me; when you post the invoice it should show up in your Accounts Receivable (or whichever account you've designated), and after you process the payment the A/R should go down accordingly.  When posting your invoice, you specify which account it gets posted to:  So that account should show a balance once you have posted it:  Then, when a client pays you, your cash will go up, and A/R will go down."
I just decided to start using GnuCash today, and I was also stuck in this position for around an hour before I figured out what to do exactly. The answer by @jldugger pointed me partially on the right track, so this answer is intended to help people waste less time in the future.  (Note: All numbers have been redacted for privacy issues, but I hope the images are sufficient to allow you to understand what is going on. ) Upon successfully importing your transactions, you should be able to see your transactions in the Checking Account and Savings Account (plus additional accounts you have imported). The Imbalance account (GBP in my case) will be negative of whatever you have imported. This is due to the double-entry accounting system that GnuCash uses.    Now, you will have to open your Savings Account.   Note that except for a few transactions, most of them are going to Imbalance. These are marked out with the red rectangles.   What you have to do, now, is to click on them individually and sort them into the correct account. Unfortunately (I do not understand why they did this), you cannot move multiple transactions at once. See also this thread. Fortunately, you only have to do this once.  This is what your account should look like after it is complete.   After this is done, you should not have to move any more accounts, since you can directly enter the transactions in the Transfer box. At this point, your Accounts tab should look like this:  Question solved! Just FYI for the benefit of future users. Haven't been paid yet nor have I paid but some interesting facts. I decided to sign the contract with the person who approached me. The contract seemed harmless whereby I only transfer money once I retrieve the funds. Thanks to your comments here I also understood that I must make sure the funds really cleared in my account and can never be cancelled before I transfer anything.  He gave me the information of the check that matched my previous employer and made sense as it was a check issues just after I had left my job and the state. I did not used the contact details he provided me, but rather found the direct contact details of the go to person in my last institution and contacted them.  I still haven't been able to reclaim the funds, but that is due to internal problems between the state comptroller and my institution. Will come back to update if I am ever successful, but the bottom line is that it is probably not a scam. I am waiting for the final resolution of the case before I post the name of the company which approached me (if it is at all OK per the discussion board rules) I believe the appropriate recourse in this scenario is to bring a court case for breach of contract.   The 1p repricing issue has been admitted as an error out of scope of the purpose of the software. You would need to use Trading Accounts. You can enable this, File->Properties->Account settings tab, and check Use Trading Accounts. For more details see the following site: http://wiki.gnucash.org/wiki/Trading_Accounts "First of all, it's quite common-place in GnuCash (and in accounting in general, I believe) to have ""accounts"" that represent concepts or ideas rather than actual accounts at some institution.  For example, my personal GnuCash book has a plethora of expense accounts, just made up by me to categorize my spending, but all of the transactions are really just entries in my checking account. As to your actual question, I'd probably do this by tracking such savings as ""negative expenses,"" using an expense account and entering negative numbers.  You could track grocery savings in your grocery expense account, or if you want to easily analyze the savings data, for example seeing savings over a certain time period, you would probably want a separate Grocery Savings expense account. EDIT: Regarding putting that money aside, here's an idea:  Let's say you bought a $20 item that was on sale for $15.  You could have a single transaction in GnuCash that includes four splits, one for each of the following actions: decrease your checking account by $20, increase your expense account by $20, decrease your ""discount savings"" expense account by $5, and increase your savings account (where you're putting that money aside) by $5." Unfortunately, there is no facility to do bulk transaction edits in GnuCash, so you are out of luck for your existing hundred. (I don't know whether there is a way to initially import a transaction as split.) However, once you have entered this split once, it can be used as a template for new transactions, using autocomplete or by entering it in the Scheduled Transaction Editor. "You don't. No one uses vanilla double entry accounting software for ""Held-For-Trading Security"".  Your broker or trading software is responsible for providing month-end statement of changes.  You use ""Mark To Market"" valuation at the end of each month.  For example, if your cash position is -$5000 and stock position is +$10000, all you do is write-up/down the account value to $5000.  There should be no sub-accounts for your ""Investment"" account in GNUCash.  So at the end of the month, there would be the following entries:" Gnucash uses aqbanking, so I'd suggest looking at aqbanking to see if it will do what you want. It seems to be actively developed (as of 26.2.2011), but the main page is in German and my German is a bit rusty... You might also try asking on the gnucash-users list. "Other responses have focused on getting you software to use, but I'd like to attempt your literal question: how are such transactions managed in systems that handle them? I will answer for ""double entry"" bookkeeping software such as Quicken or GnuCash (my choice). (Disclaimer: I Am Not An Accountant and accountants will probably find error in my terminology.) Your credit card is a liability to you, and is tracked using a liability account (as opposed to an asset account, such as your bank accounts or cash in your pocket). A liability account is just like an asset except that it is subtracted from rather than added to your total assets (or, from another perspective, its balance is normally negative; the mathematics works out identically). When you make a purchase using your credit card, the transaction you record transfers money from the liability account (increasing the liability) to the expense account for your classification of the expense. When you make a payment on your credit card, the transaction you record transfers money from your checking account (for example) to the credit card account, reducing the liability. Whatever software you choose for tracking your money, I strongly recommend choosing something that is sufficiently powerful to handle representing this as I have described (transfers between accounts as the normal mode of operation, not simply lone increases/decreases of asset accounts)." "Fees & liabilities Yes, the first problem is that liabilities are being improperly booked. If the fee you charge is fixed upon deposit then the fee should credit ""Revenue"", the fee charged to you should be booked by crediting cash and then debiting ""Expenses"", and the remaining should be booked as a liability. If the fee is fixed upon withdrawal then this will become more complex because of the fact that a change in the fee can occur before it can be applied.  In this case, the current fee should be credited as ""Revenue"" and some ""Allowance for fee increase"" should also be credited.  The amount owed to the withdrawer should be booked as a liability as before. Multiple currency bookings I will assume that this is for a cryptocurrency service of some sort considering the comments in your question and your presence on bitcoin.se. Accounting can become very dangerous when mixing denominations.  This is why all major accounting standards mandate books be maintained single currency. In your case, if the deposit is in USD, for example, and the liability is in BTC then two books must be maintained, one for each. To account for your operation properly using single currency accounts, the denominations must be exchanged internally and balanced across the two sets of books. For a deposit of BTC/depository of USD, the operation would be the same as described above, but then the cash should be credited away and the liabilities debited away from the USD books with simultaneous cash debits and liability credits on the BTC books. Considering the extreme volatility of cryptocurrency exchange rates, denominating accounts on the wrong set of books will quickly lead to insolvency or loss from improper accounting or both. From revenue to income Revenue can be construed as a liability since it could theoretically exist on the balance sheet. I mention this because all books, despite their name and quarter, are really simply long T accounts, like a blockchain.  A blockchain could be subdivided into users' individual income statements & balance sheets, as the reverse of this concept. Revenues are credited, expenses are debited.  The difference, ""net income"", is debited away with a credit to ""owners' equity""." Usually payments are applied towards: "I recently needed to compute a better balance that let us pick and choose what to include in the computed sum without losing information, so I revisited this topic and I'm pleased to say that I've found a solution that works (at least for our data - you may have transactions that this code doesn't recognize, but you can always modify it to match). My solution was written natively for MS SQL Server 2008 or later, it uses a scalar UDF, a VIEW, and a windowed aggregate (SUM OVER (ORDER BY ...) which means it should be almost-syntax compatible with PostgreSQL. MySQL does not support OVER but you can perform a running-sum using a variable with arithmetic addition directly in the SELECT clause. Create a database table with this schema (feel free to exclude columns you're not interested in, such as Option1Name): Create a UNIQUE index on TxnId - you could use it as a primary-key, I suppose. You might be tempted to create a Foreign-Key relationship between ReferenceTxnId and TxnId, however this will fail if you enforce it: we have many transactions where ReferenceTxnId points to a Transaction that doesn't exist. This is usually in the case of [Type] = 'Web Accept Payment Received' AND [Status] = 'Canceled'. We also have some TransactionId values longer than 17 characters: some TransactionIds start with ""U-"" - all pending money requests, I suspect this indicates the transaction is ""unfinished"". Re-download your entire PayPal History CSV files so that you have the latest retroactive updates. Import these CSV files into this PayPalHistory table. Do a simple test to see how bad PayPal's default data is: To find out where the differences are coming from, run this query: (The ORDER BY (...), RowId is to ensure consistent ordering when multiple transactions share the same timestamp) As you scroll through the results, you'll see how the naive SUM is thrown-off from the official PayPal-computed Balance column. So as you can see, the Net column value cannot always be trusted - what we need is to generate our own ""EffectiveNet"" value which is accurate - that is, the value is 0.00 for rows which do not affect the balance, instead of being what they are right now. The problem is, given a single row of data (such as any single row from the example table in my original Question) we have no way of inherently knowing what its ""EffectiveNet"" is. I have devised two functions to help solve this problem, the first function only looks at the ReferenceTxnId, Type and Status column values and generates accurate values for the vast majority of rows - indeed, in our dataset we only had one row for which this approach did not work. I recommend you try this one first and compare the running-sum value to ensure it works for your data: You can use this function in the query like so below, hopefully it should give you an accurate running-sum and balance figure at the end: 8. And here's the view that ties it all together: Used like so: I hope this helps anyone else wanting to do accurate bookkeeping with PayPal Transaction History files!" Really a very straightforward situation, and subsequently, answer.  Call the university pursors that you normally deal with, ask them to document the last 3 months of disbursements and highlight the incorrect one(s). If the money is already spent out, ask them if they can apply it to future disbursements via adjusting entries, and call it a day.  If not, and you CAN pay it back, go to your bank and ask them to figure it out...which they should be able to do, having the original sender's info. "You should have separate files for each of the two businesses.  The business that transfers money out should ""write check"" in its QB file.  The business that receives money should ""make deposit"" in its QB file. (In QB you ""write check"" even when you make the payment by some other means like ACH.)  Neither business should have the bank accounts of the other explicitly represented.   On each side, you will also need to classify the payment as having originated from / gone to some other account - To know what's correct there, we'd need to know why your transferring the money in the first place and how you otherwise have your books established.  I think that's probably beyond the scope of what's on-topic / feasible here. Money into your business from your personal account is probably owner's equity, unless you have something else going on.  For example, on the S Corp you should be paying yourself a salary.  If you overpay by accident, then you might write a check back to the company from your personal account to correct the mistake.  That's not equity - It's probably a ""negative expense"" in some other account that tracks the salary payments." Instead of gnucash i suggest you to use kmymoney. It's easier