- My Forums
- Tiger Rant
- LSU Recruiting
- SEC Rant
- Saints Talk
- Pelicans Talk
- More Sports Board
- Fantasy Sports
- Golf Board
- Soccer Board
- O-T Lounge
- Tech Board
- Home/Garden Board
- Outdoor Board
- Health/Fitness Board
- Movie/TV Board
- Book Board
- Music Board
- Political Talk
- Money Talk
- Fark Board
- Gaming Board
- Travel Board
- Food/Drink Board
- Ticket Exchange
- TD Help Board
Customize My Forums- View All Forums
- Show Left Links
- Topic Sort Options
- Trending Topics
- Recent Topics
- Active Topics
Started By
Message
Accounting for arbitrary/abstract "commodities" (tickets, memberships, etc)
Posted on 9/2/20 at 1:58 pm
Posted on 9/2/20 at 1:58 pm
This is likely a stupid question/idea, but here goes. I'm trying to keep a ledger for a small organization, and accounting for cash is simple and straightforward, but I'm struggling with what I feel should be a basic accounting principle for things other than cash.
I don't believe it matters, but just in case it does, I'm using something called "ledger-cli", which I guess I would describe as accounting software for the technically-minded. It has all the tools required for accounting for any arbitrary commodity you'd like to define, whether it's dollars, pesos, hours, widgets, or whatever, and for generating any type of report you can imagine.
I guess I just haven't been able to wrap my head around accounting for "imaginary" items, or how to structure the accounts for them.
Take ticket sales to an event, for example. Handling the cash is easy (I think):
Assets:Cash $10
Income:Tickets $-10
But I also need to account for the "ticket". Physical tickets are not issued, but even if they were issued it shouldn't be required in order to attend the event. Instead, the "ticket" will appear in the member/customer's account, and it will be "redeemed" in another accounting transaction after the event takes place.
So if I do something like the following at the time of the sale:
Members:John 1 "ticket"
[???] -1 "ticket"
I can generate a report that shows John has a ticket, but how should I conceptualize the account the ticket comes from? It's a liability, right? John is owed entry to the event until it is redeemed:
Members:John -1 "ticket"
Liabilities 1 "ticket" (to bring Liabilities back up to 0 tickets owed)
But then what account keeps the total tickets sold? And how should those transactions look?
Am I missing something simple, or am I thinking about this all wrong? Am I looking at it from the wrong POV, and instead of John's account having a balance of 1 ticket, it should instead be a liability account?
Obviously my accounting knowledge is lacking, so thanks in advance for any help or input.
And I know this seems overly complex trying to do accounting for tickets, and maybe it is. But if I can distill the accounting of arbitrary commodities down to a set of simple transactions between structured accounts, I can extend this concept to several other aspects of the organization and unify the reporting of all statuses. For example, members perform tasks in order to earn achievements, and they are then owed (and eventually given) an award. So far this has all been tracked on spreadsheets, but it gets really messy, really fast, and it's a real headache jumping sheet to sheet to check who's done what, who is owed what, how many awards to buy, etc. I think all of this would be greatly simplified with a simple chronological ledger of transactional events as the source of truth, and then any question you might have about the status of the organization can be answered with a report.
I don't believe it matters, but just in case it does, I'm using something called "ledger-cli", which I guess I would describe as accounting software for the technically-minded. It has all the tools required for accounting for any arbitrary commodity you'd like to define, whether it's dollars, pesos, hours, widgets, or whatever, and for generating any type of report you can imagine.
I guess I just haven't been able to wrap my head around accounting for "imaginary" items, or how to structure the accounts for them.
Take ticket sales to an event, for example. Handling the cash is easy (I think):
Assets:Cash $10
Income:Tickets $-10
But I also need to account for the "ticket". Physical tickets are not issued, but even if they were issued it shouldn't be required in order to attend the event. Instead, the "ticket" will appear in the member/customer's account, and it will be "redeemed" in another accounting transaction after the event takes place.
So if I do something like the following at the time of the sale:
Members:John 1 "ticket"
[???] -1 "ticket"
I can generate a report that shows John has a ticket, but how should I conceptualize the account the ticket comes from? It's a liability, right? John is owed entry to the event until it is redeemed:
Members:John -1 "ticket"
Liabilities 1 "ticket" (to bring Liabilities back up to 0 tickets owed)
But then what account keeps the total tickets sold? And how should those transactions look?
Am I missing something simple, or am I thinking about this all wrong? Am I looking at it from the wrong POV, and instead of John's account having a balance of 1 ticket, it should instead be a liability account?
Obviously my accounting knowledge is lacking, so thanks in advance for any help or input.
And I know this seems overly complex trying to do accounting for tickets, and maybe it is. But if I can distill the accounting of arbitrary commodities down to a set of simple transactions between structured accounts, I can extend this concept to several other aspects of the organization and unify the reporting of all statuses. For example, members perform tasks in order to earn achievements, and they are then owed (and eventually given) an award. So far this has all been tracked on spreadsheets, but it gets really messy, really fast, and it's a real headache jumping sheet to sheet to check who's done what, who is owed what, how many awards to buy, etc. I think all of this would be greatly simplified with a simple chronological ledger of transactional events as the source of truth, and then any question you might have about the status of the organization can be answered with a report.
3
Posted on 9/2/20 at 2:53 pm to Korkstand
Depends on what basis of accounting you’re doing. Cash basis it would simply be you got the cash you recognize revenue. Accrual Basis you use deferred Revenue.
But from the sounds of it you’re looking for Deferred Revenue which yes is a liability because you received the cash but haven’t performed the service. So in essence you owe them the service.
So entries would be:
(Ticket Sold)
DR Cash
CR Deferred Revenue
(Ticket Redeemed)
DR Deferred Revenue
CR Revenue
But from the sounds of it you’re looking for Deferred Revenue which yes is a liability because you received the cash but haven’t performed the service. So in essence you owe them the service.
So entries would be:
(Ticket Sold)
DR Cash
CR Deferred Revenue
(Ticket Redeemed)
DR Deferred Revenue
CR Revenue
This post was edited on 9/2/20 at 2:54 pm
Posted on 9/2/20 at 3:25 pm to Korkstand
Think of the ticket as a service you took money and you owe the service. You have obligation /Liability to perform service. That is deferred revenue (balance sheet Liability account). When you perform service you earned revenue.
The flip side if the organization pays for setting they have not gotten it is an asset called prepaid.
The flip side if the organization pays for setting they have not gotten it is an asset called prepaid.
Posted on 9/2/20 at 3:34 pm to Weagle25
That is just an alternative way to handle the money though, right? It still doesn't give me a way to report who has bought a "ticket" for which event. And it doesn't give me any hints as to how to handle accounts and transactions that don't involve money at all, as in the tasks/achievements/awards example.
Maybe I am asking the wrong questions, or asking them in the wrong way. Or maybe it's not specifically an accounting question at all, and I should instead approach it as a programming problem since accounts are just variables.
Maybe I am asking the wrong questions, or asking them in the wrong way. Or maybe it's not specifically an accounting question at all, and I should instead approach it as a programming problem since accounts are just variables.
Posted on 9/2/20 at 3:39 pm to Korkstand
quote:
That is just an alternative way to handle the money though, right? It still doesn't give me a way to report who has bought a "ticket"
I don't know your tool so report for who bought ticket I don't know. It is more accrual vs cash basis accounting.
If it makes you feel better I have $90m in deferred rev on excel lol
quote:
how to handle accounts and transactions that don't involve money at all, as in the tasks/achievements/awards example.
Accrue liabilty as they earn credit. Tracking I am not sure.
Again we are giving you accrual base accounting tips not sure on your tool
Posted on 9/2/20 at 3:49 pm to thelawnwranglers
quote:Yeah I think I have a handle on these concepts. My issue is I am struggling to apply the same ideas to arbitrary items that are not money. If I convert all of my obligations to dollars, consider if I sell tickets to two events at different prices, with some members/customers attending one, both, or neither. My deferred revenue account in terms of dollars doesn't help me on the day of Event #1 when I need to know who to allow inside. Maybe if, in addition to or instead of dollars, I put quantities of "Event1Ticket" and "Event2Ticket" in that account? And those transactions would balance against individual Member accounts in terms of those same abstract commodities?
Think of the ticket as a service you took money and you owe the service. You have obligation /Liability to perform service. That is deferred revenue (balance sheet Liability account). When you perform service you earned revenue.
The flip side if the organization pays for setting they have not gotten it is an asset called prepaid.
Maybe that's just a hard thing to do, to translate the language and methods of financial accounting to another area.
Posted on 9/2/20 at 3:55 pm to Weagle25
This is right on the accounting side. Unless you have some kind of built in customer tracking software, you will still need to separately track your deferred revenue account in excel and reconcile this sheet to the GL. In your excel you would have a row for every customer and the number of tickets and total price of the tickets for that specific customer. All the rows of customer and their totals should tie to what you have booked in the account.
If your strictly just wanting to see total tickets sold, You could always create an account called "control account" below your income statement accounts, and then everytime you sell a ticket credit the control account and debit a "tickets sold" account. You could get creative this way and set up different types of accounts to track the different types sold but to set up one for each customer would get very messy.
If your strictly just wanting to see total tickets sold, You could always create an account called "control account" below your income statement accounts, and then everytime you sell a ticket credit the control account and debit a "tickets sold" account. You could get creative this way and set up different types of accounts to track the different types sold but to set up one for each customer would get very messy.
Posted on 9/2/20 at 3:57 pm to Korkstand
First, it does sound like you need to move to accrual based accounting as Weagle suggested since you want to capture deferred revenue.
It also sounds like you want the revenue of John's ticket to also be assigned to John's ticket number which would then be tied to John's account. Is that right?
If so, that is a pretty complicated ask for most accounting software platforms, but it could probably be built, depending on what you use. You should be able to tie the revenue to John's account if you're using something like Quickbooks, but I don't know that you would be able to track ticket numbers under John's account on top of that.
You could use excel, if the volume is low enough, to track everything or possibly set up statistical accounts within your accounting software to track tickets. But, if you do the latter, you still probably won't be able to "attach" the tickets to the individual accounts unless someone built that logic for you.
It also sounds like you want the revenue of John's ticket to also be assigned to John's ticket number which would then be tied to John's account. Is that right?
If so, that is a pretty complicated ask for most accounting software platforms, but it could probably be built, depending on what you use. You should be able to tie the revenue to John's account if you're using something like Quickbooks, but I don't know that you would be able to track ticket numbers under John's account on top of that.
You could use excel, if the volume is low enough, to track everything or possibly set up statistical accounts within your accounting software to track tickets. But, if you do the latter, you still probably won't be able to "attach" the tickets to the individual accounts unless someone built that logic for you.
Posted on 9/2/20 at 4:09 pm to Weagle25
quote:
Depends on what basis of accounting you’re doing. Cash basis it would simply be you got the cash you recognize revenue. Accrual Basis you use deferred Revenue.
But from the sounds of it you’re looking for Deferred Revenue which yes is a liability because you received the cash but haven’t performed the service. So in essence you owe them the service.
So entries would be:
(Ticket Sold)
DR Cash
CR Deferred Revenue
(Ticket Redeemed)
DR Deferred Revenue
CR Revenue
This is correct. Assuming the accounting tool is simply a general ledger and does not have a sales/customer module that feeds to the GL. Do you have the ability to extract the ledger detail in excel format? If so you could assign a unique ticket # to each description, and pivot all ticket sold and ticket redeemed transactions to see status of each ticket.
Posted on 9/2/20 at 4:12 pm to thelawnwranglers
quote:Yeah, and again my accounting knowledge is weak, so I understand and apologize that there is a language barrier here.
Again we are giving you accrual base accounting tips not sure on your tool
Would it help if I say that none of this has anything to do with taxes or finances at all?
In other words, I can just handle the money on cash basis, recognize it as income at the time of the transaction. Whether it's the sale of a physical item, or a ticket to a future event, or whatever, it just doesn't matter. The total of cash flowing through the organization annually amounts to a rounding error for a mom&pop business. The finances are inconsequential. I just thought it would be ideal to handle all of these other commodities as if they were cash.
In the simplest terms that I can think of, here is how I would describe what I want to do:
We have a couple dozen "members", so I want each member to have an account. In these accounts I would like to "bank" things like hours worked, tickets held for specific events, awards owed to them, etc. In addition to monetary things like fundraising items sold and donations.
I'm sure it seems like I'm making this more complicated with every post, but I just know that if I keep talking it out I can arrive at an account structure and a set of transaction templates that simplify and streamline all of this, and eliminate the reliance on accounting software and spreadsheets and a hodgepodge of other tools that complicate things or cost money. Because again, we aren't dealing with much money here, and the intent is not to make any.
Posted on 9/2/20 at 4:23 pm to FinleyStreet
quote:Basically yes.
It also sounds like you want the revenue of John's ticket to also be assigned to John's ticket number which would then be tied to John's account. Is that right?
quote:I've noticed.
If so, that is a pretty complicated ask for most accounting software platforms
quote:The current method uses excel/google sheets, but it gets messy very quickly. And every time I consider how to simplify it and eliminate errors, I always fall back on the idea of a simple ledger with reporting tools to extract whatever information is necessary, on demand.
You could use excel, if the volume is low enough
The tool I have found to do that is called ledger-cli. My struggle is mostly in how to structure the accounts. I think I keep falling into the trap of trying to fit this into the assets/liabilities/equity/income/expenses tree, but it just doesn't fit. I just need to wipe what little accounting knowledge I have and start from the ground up with accounts that fit the purpose of moving arbitrary items between accounts.
Posted on 9/2/20 at 4:29 pm to Korkstand
As others have said, I think the concept you are looking for is deferred revenue. But, a "small organization" is likely not going to need to, or want to, be on the accrual basis.
So when a customer buys a ticket, debit cash, credit ticket revenue. Yes, you "owe" them something still, if the ticket purchase is in advance. You owe them an admission, a performance, whatever it is that the ticket is redeemable for.
Is the ticket refundable? If it is, and the customer wants a refund, you just debit ticket refunds, and credit cash.
If the ticket is non-refundable, then I think your accounting is complete at the time of sale.
I think the real issue is, you need to track who has what tickets, and when they are redeemed, since they are not paper tickets. That's not an accounting problem, that's an operational problem. There are a number of programs/apps out there that handle virtual ticketing.
So when a customer buys a ticket, debit cash, credit ticket revenue. Yes, you "owe" them something still, if the ticket purchase is in advance. You owe them an admission, a performance, whatever it is that the ticket is redeemable for.
Is the ticket refundable? If it is, and the customer wants a refund, you just debit ticket refunds, and credit cash.
If the ticket is non-refundable, then I think your accounting is complete at the time of sale.
I think the real issue is, you need to track who has what tickets, and when they are redeemed, since they are not paper tickets. That's not an accounting problem, that's an operational problem. There are a number of programs/apps out there that handle virtual ticketing.
Posted on 9/2/20 at 4:31 pm to LSUFanHouston
quote:
There are a number of programs/apps out there that handle virtual ticketing.
EventBrite is pretty idiot proof.
Posted on 9/2/20 at 5:10 pm to LSUFanHouston
quote:Right, it's not precisely an accounting problem, but it is a problem that can be solved with accounting.
I think the real issue is, you need to track who has what tickets, and when they are redeemed, since they are not paper tickets. That's not an accounting problem, that's an operational problem.
So here's the thing, and I think this applies to a lot of operations, if not every operation. "Use the right tool for the job" is very solid advice, but if you always use the exact right tool for every single job, eventually you have a new problem: too many tools.
In my case, I am using one tool for financial accounting, another tool for event registration, another tool for time tracking, another tool for misc event logging, etc. I am only ever dealing with maybe 40 members/customers tops, but there is a *lot* of activity that must be recorded, and a lot of it is not financial but still related to the finances in some way.
So all of these disparate tools fit their purpose pretty well, but there is little integration. As a result, it is difficult to answer certain types of questions.
My idea is to, instead of using tools that perfectly fit a given set of problems, use a more generic tool and modify the problems slightly to fit the tool. In other words, the "right tool for the job" seems to be to modify the jobs.
If a member asks me "how much do I owe, am I registered for X event, and how far am I from earning X award?", currently I have to pull up the accounting package, then pull up the ticketing tool, then pull up the spreadsheet, and then hope it's all been updated properly to be in sync. I'd like to instead reduce every event down to a simple balanced transaction and store it all in the same format to be processed by the same tool. That way I can run a status report for a given member and instantly have the answer to any question they could have.
Posted on 9/2/20 at 5:45 pm to Korkstand
quote:
In my case, I am using one tool for financial accounting, another tool for event registration, another tool for time tracking, another tool for misc event logging, etc. I am only ever dealing with maybe 40 members/customers tops, but there is a *lot* of activity that must be recorded, and a lot of it is not financial but still related to the finances in some way.
Yeah this is a pretty standard issue in the GL accounting world, unfortunately. Lots of databases doing different things and none of them "talk" to each other.
You could probably get an IT guy to write some kind of SQL code that dumps the results into excel based on the criteria you need. I've had to do that in the past.
Posted on 9/2/20 at 6:05 pm to Korkstand
quote:
That is just an alternative way to handle the money though, right? It still doesn't give me a way to report who has bought a "ticket" for which event. And it doesn't give me any hints as to how to handle accounts and transactions that don't involve money at all, as in the tasks/achievements/awards example.
Well I know in like quickbooks you would be able to tie those entries to certain customers.
I would also probably set up different revenue & deferred revenue accounts for each event. Then you’d be able to pull reports by customer and see what events they have tickets to or you could pull a report for each event and see which customers have tickets.
As for the non-cash stuff, I would definitely keep that separate from my financial stuff. Just going to make things wonky.
But as the other guy said, I don’t know your tool so can’t tell you what you can or can’t do in it.
This post was edited on 9/2/20 at 6:06 pm
Posted on 9/2/20 at 6:08 pm to FinleyStreet
quote:This is part of the problem I'm trying to solve. I don't want to use a database. Instead, I want all of my data in a standardized, text-based, human-readable format that I can manage with standard version control tools like git.
Yeah this is a pretty standard issue in the GL accounting world, unfortunately. Lots of databases doing different things and none of them "talk" to each other.
quote:I am an IT guy.
You could probably get an IT guy to write some kind of SQL code that dumps the results into excel based on the criteria you need. I've had to do that in the past.
I could easily dump everything to spreadsheets if I want, but that is kind of going backwards IMO. A lot of stuff is in spreadsheets already, and it's just a clunky tool for what I need to do.
I'm trying to get my data out of databases and spreadsheets, and instead store it in a standardized format that any arbitrary tool can use. Then I will have a single source of truth for all of the data relevant to the operation, and it can all be backed up simply and with unlimited version history via git.
If only I could figure out how to account for arbitrary widgets.
I really think I just need to mock up a program, and then translate the variables that I end up with into a chart of accounts. I will report back when I think I have it solved.
Posted on 9/2/20 at 6:21 pm to Korkstand
quote:
I really think I just need to mock up a program, and then translate the variables that I end up with into a chart of accounts. I will report back when I think I have it solved.
Get a patent and start selling it when you're done.
Posted on 9/2/20 at 8:34 pm to FinleyStreet
quote:I don't really plan to end up with anything all that valuable. I was just going to think about this problem from the programming angle, and rough it out so that hopefully I can wrap my head around the variables at play here. I will just have to not get too fancy with it, make sure every operation can be accomplished by just moving amounts between variables. It will just be an exercise that helps me to understand what needs to happen for accounting purposes.
Get a patent and start selling it when you're done.
After that, I'm just going to translate the variables into accounts, and the functions into balanced transaction templates. I'm going to utilize a format that is already a de facto standard for plain text accounting, so no innovation there, either.
Check out the tool I will be using here, you guys will think I'm crazy.
Posted on 9/2/20 at 8:57 pm to Weagle25
quote:For me there is a lot of beauty and power in the simplicity of plain text data.
As for the non-cash stuff, I would definitely keep that separate from my financial stuff. Just going to make things wonky.
But as the other guy said, I don’t know your tool so can’t tell you what you can or can’t do in it.
The data format is so simple that I can type it out by hand with any text editor on any device. This also means that it's easy to write a script that can do rapid data entry, or bulk data entry/editing, or whatever you need. Likewise it's easy to create a GUI app or a mobile app to do the same.
As for keeping non-cash separate from cash, this is yet another strength of this very simple tool. I can keep a file called financial.journal, and another file called events.journal, and any number of other files with arbitrary names and data. As long as they all use the same basic data structure (balanced transactions), I can run reports however I wish. I can pick and choose which files I want to be included in the report. If I just need financial data, I just use that file. If I want all data related to a particular member account, I'll include all the files to generate a report with their cash balance, fundraising data, achievement progress, etc.
And again, I'm sure this seems complicated and like a lot of work to most of you, but I assure you that almost all of the hard work has already been done by others, and the principles and systems make perfect sense to me. At this point it's just a matter of me being able to make sense of handling arbitrary commodities in a double-entry accounting system. The tooling doesn't care whether you're shuffling around dollars or donuts, as long as each transaction balances to zero (and even then you can force a non-zero balance with "virtual" postings, but that's kind of irrelevant at this point).
Page 1 of 2
Popular
Back to top
Follow TigerDroppings for LSU Football News