Episode Summary
In this episode, our host Zach Malloch is joined by the Director of Municipal Support Services, Cullen Barber, and Implementation Manager, Brian Hatch to discuss the role of the control general ledger (GL) account. The group touches on how your GL account can be set up in the static parameters profile, how to report on household balances and credits, and how money moves through the RecTrac solution.
Recording
Transcript
Zach Malloch 0:41
And that must mean that it's time for RecChat, special edition or special month, we have fourth or three Thursdays this month. And if you happen to be on any of the credit card, distribution sides, you might even get a bonus on one of these Tuesdays. It's the most read chat month ever. Speaking of that, welcome, everybody to participating in this edition about the control balance and refund accounts. And I'm joined by Cullen Barber, who's going to be assisting with questions and like how are you Cullen?
Cullen Barber 1:11
I'm pretty good. How are you doing?
Zach Malloch 1:13
Not too bad at all. And we're also joined by Brian hatch, and I'm not going to put him on the spot immediately. He's just coming in off of another session. Welcome, Brian.
Brian Hatch 1:23
How you doing?
Zach Malloch 1:24
Very good, are you? Awesome. So as we do all the time, I'm going to direct everybody's attention to the QA Button down at the bottom of the Screen. If you do have questions, we'll get to as many of them as we can. Understandably, finance is kind of a complicated topic. A lot of people have very specialized questions. So if it becomes something that's more focused just for you, we might not be able to get to all of the questions, but we'll definitely talk about everything that we can today. So Brian, would you like to kick us off with this conversation?
Brian Hatch 1:55
I was afraid you're gonna say that, Zack,
Zach Malloch 1:57
I had this question. What is the control account?
Brian Hatch 2:01
Yeah, so the control account is really a account that we use for kind of transitioning or the most common example I always lean on is an activity transfer scenario where somebody is moving from activity A and go into activity B, and we're going to assume there's two revenue accounts in that scenario, we're going to take the debit the money out of revenue A, and we're going to put the money into the control account. And then we're going to debit the money out of that control account as a transition to activity B and revenue B. So it's basically used to for internal movement to move between different jails.
Zach Malloch 2:43
And so I'm just bringing up our static parameters Profile, because that is where we can actually see some of this financial information. So this is where we define what the control account actually is. And as Brian was talking in mentioning, there's a very definite reason I also saw Denise suggesting that potentially, the control account is a mysterious black hole. And we try not to make it too mysterious. But I mean, like kinda to that that direction or that question, one of the reasons that the control account can be confusing, is if you happen to go into your Profile, your static parameter Profile, and if you notice your control account, code is the same as your refund apply and finance and now, or if there's any duplication between these, that's where we could potentially run into an issue where we have an uncertain amount of information in there, we might be left over with some some components or some run balances
Brian Hatch 3:38
the control account, if all by itself, right, that one control account line you're pointing to there. If it's a specific GL, it's always actually going to net to zero, right? It's right. There's never going to be money in the control account, unless there's some sort of issue. But like you said, if it's the same one link over then changes things a little bit.
Cullen Barber 3:58
Right. When you say it nets to zero it basically after each transaction, right. It's not like end of day or in a month. It's it's almost immediately, right.
Brian Hatch 4:07
Exactly, yep.
Cullen Barber 4:08
Yeah. Yep. Thanks.
Zach Malloch 4:11
Yeah. And so this is actually an interesting thing. So just a real quick aside. But while Brian and I were preparing for the session today, I realized that I had an inaccurate assumption about the way the control account works. So effectively, if if this was a transfer, like imagine that we're moving from program one revenue over to program to revenue, that would be the scenario that Brian just described in the previous example that he was talking about. And in that case, we would see the $50 credit and debit from the control account. And this is the Type of activity we will always expect to see in the control account once again, as long as the control account is really specified as a separate account than the credit balance control account or the refund apply account. And yes, and we can get into a little bit more detail about it. exactly how those transactions posted. I know there's some other things we wanted to talk about with those refund accounts right brain.
Brian Hatch 5:07
Correct? Yeah. So the going back to stack parameters that you had up the, we have the ability to link separate jails to each, each individual refund Type, right. So we've got a refund, apply refund, finance and refund now, the so these are, depending on the Type of refund, this count is going to be hit. So we really, we recommend, and that's why they're separate fields going with separate GLS for those different refund types. It's not required. And I've actually seen different databases go different with the go with different setups. But having it separate from your control account is definitely one thing that I guess I would recommend for any customer. And we can talk a little bit more about maybe some scenarios to this.
Zach Malloch 5:57
Yeah, and I guess I wanted to also just add on to that slightly. So we also have these areas where we can assign GL codes directly to each of the fees. So if we wanted to have a different refund finance account or refund now or refund apply account for different fees, we can do that, you know, it's there's not a control account on a per fee basis, because that control accounts the system account setting, that's why it's only in the static parameter piece. So everything will default to what you have in static parameters unless you override it and put something else in here. And just really briefly, this refund GL Code is actually the offset, refund GL Code, whereas these are the functional GL codes. So like where's the money hanging out during the refund process, versus if we went to offset our revenue with a particular GL Code and take refunds out of that instead of normally it'd be out of this revenue account. But anyway, just a real quick aside,
Brian Hatch 6:55
yeah, if there's ever two different, I guess organizations in the same account, that's might be where you get into that fee level setup, the bigger the organization, the product organization that takes up most of the fees, and most of the setup would probably use the system defaults, and then and statics and then whatever the other part of the organization is that needed that separate refund setting, their fees would probably be set up with their separate accounts, is what I would see.
Zach Malloch 7:20
Exactly. Yeah. So I think that's, uh, did you want to go over any of those examples, Brian for the refund accounts.
Brian Hatch 7:31
Sure. So again, the recommendation would be if anybody's looking at their database, they really, we would recommend there being a separate refund apply. And separate refund finance account. When one possible, it just is gonna make the benefits to that. And one of the benefits is, it makes troubleshooting a little bit easier, right. So if there's ever an issue with one of these accounts, you can actually you can pinpoint it a little bit quicker, right, or you see that, oh, that's hitting my specific refund apply account, well, then you immediately kind of know it's has something to do with the refund apply and household credit, versus the refund finance or refund now. So just the fact that you're splitting them out into separate GLS will kind of open the door to making troubleshooting a little bit easier. If there was the same account linked on all these, it just makes more details and more records that you're potentially maybe sifting through and troubleshooting when there are issues that arise. So that's one of the reasons we recommend that. One thing I always like to point out is the account in the background, right, the actual account that's linked to these four, three different refund options can actually be the same account on the finance side. So it's not like you have to have on the in their financial software. Three separate refund accounts, you can have one account and that can be linked to our separate are three separate GL. So essentially, it gives you the flexibility on the RecTrac side to be able to split things out and run reports separately. But ultimately, they can funnel through your GL interface or through your GL report to one. One single financial account.
Zach Malloch 9:13
Absolutely. Yeah, and I mean, I think the the core piece of that is just really we need somebody ready to catch any information that we might be sending. So even though 99% of the time there should never be a balance and X number x account, we should have it over there just in case because otherwise you're going to throw an error during your your interfacing process and having something that has a place to go then you can at least change what place it needs or that it could be rather than not even knowing where to put it. And then you mentioned the interface. Brian Oh, actually I see. There's a quick question. Cullen, do you want to mention that?
Cullen Barber 9:51
Yeah, Patti had a good question. Can you have can you apply refunds back to the same account they were originally charged against? On each Activity Registration or facility Rental? So I think I think what Patti is looking for is actually our default, right? Where if you have money coming into a revenue account, if you don't specify a refund GL, the system is going to automatically debit it out of the revenue account. Right? It's only if you specify a refund GL, that it will, it'll keep it in the revenue account. But then take it out of the refund account. Is that Mike describing that accurately, guys?
Zach Malloch 10:30
Yeah, exactly. So like in this case, we would be taking $5 into this GL Code every time we charged for this particular Type of transaction. And then if we refund it, we're going to take $5 out of this GL Code to give back to the customer. But if I put in an offset, refund GL Code, like just as an example, here, I use number five, every time I take this payment, I'm putting the money into this GL Code, that every time I'm refunding it, I'm taking it out of this GL Code. So if you're ever looking at your line item in your financial system for how much is in this account, it's going to be inflated, and you'll have to offset it with whatever the negative balances in your refund GL account.
Cullen Barber 11:09
Yeah, there's some some places that like to see if money came in, right? It's ah, stays as revenue, if it comes out, it's it's an expense, maybe. So they don't want to hit a revenue account as an expense. So that's why the separate offset refund account might be a good idea for those organizations.
Zach Malloch 11:27
Absolutely. Yep. And that's mostly the time that it comes in. And it's you're always going are, it seems like it's always going to be a decision that finance makes in the way that they like to see things and whether they like to be able to look on their system to be able to identify what refunds were occurring, or if they're willing to interact with RecTrac and run reports from from that side of things.
Cullen Barber 11:49
Like, I guess there's a bit of time to the follow up question to that. Jamie is kind of expanding, says if we decide to switch or split our various refund GL codes into new GL is, can this be done at any time? Or are there considerations that need to be addressed beforehand, like making sure all existing balances are used first? So suddenly, what are the consequences of changing your refund GLS kind of partway through when you have existing transactions out there?
Zach Malloch 12:18
Well, I have some theories about that. But Brian, I wonder if he might have any more direct experience,
Brian Hatch 12:23
I think it might matter which ones we ultimately change is what I'm thinking right? Like the going back to those options? I'm sure you're thinking the same thing? If if I guess we're assuming probably that the if they're all the same, and then we're making the change. I feel like the refund now one would be one that you would want to change, right? If they because that one's always going to, it's always going to be refunded for credit card, for example, right? We're going to credit and then debit it. So if we were to switch that one and make that one specific, I think it would be a zero impact right at that point, as long as there's not an actual actual transaction going on at the time you switch it. But
Zach Malloch 13:02
right, yeah, the regional finance should be the same way. Like it should always net to zero, because we're only like, we're basically applying the debit and the credit at the same time for those. So yeah, the the apply the credit balance account is the one that might have some stuff going on in it where we have those balances,
Brian Hatch 13:20
I feel like that one would be the one you'd want to buy leave as is right, whatever account. So if all four of these were the same, I would say all three of those were the same, I would say that's the one, leave that one where for whatever was set to maybe it'd be the easy thing to do. And then,
Zach Malloch 13:35
this one will be the one carrying any balances. And like it might even like, if you were installed in an earlier version of 3.1, then you might see something like this. And they're all the exact same account. So basically it was Brian was saying is that if they are exactly like this, let this be your refund, apply account and then set a different account for your control your refund finance and your refund now, because those should be non balanced carrying accounts. And then any balance that exists, you're just leaving in this, whatever it is, and you can go to General Ledger management, just jumped in there real quick, although I'm sure everybody knows how to get there.
Cullen Barber 14:17
While you're describing it, too, I guess the other thing that you could do is do a mass posting right, you could kind of after close a business one day, you could get your balance in that account. And you could make a change to your GL in and, you know, do a debit credit to move the money to the new new GL if you want it to, but that your idea is a little little easier to
Zach Malloch 14:41
Yeah, and I think it's a little bit I would be a little bit worried because those those general ledger postings that like created the credit in the control account or in the credit balance account, the refund apply account would have had the old GL Code entry in it at the time that those were made. So then when you affect those entries, it could be offsetting those prior Are I just so I, that's a piece I would I need to test out for I would be confident in saying it. But basically this is I just wanted to show you can change the name of it. So if if you want to make that change, they're all the same right now and you want to make this change. I'd say just go and change this to be the refund, apply account and then make however many other accounts, you would need to cover that. Okay, good question, though. And it seems like that might have spawned some others as well.
Cullen Barber 15:31
Yeah, there's
Zach Malloch 15:32
one thing I did want to mention real quick. And, Brian, we were talking about refund finance. And you had mentioned a couple of times the interfacing process that a lot of people are doing. And I just want this kind of talks a little bit about pay codes as well. I'm going a little bit off the rails slightly. No, that's a code restriction, not paycode management.
It's payment code, isn't it? Alright, so you guys should all have these, these pay codes set up. These are all of your system pay codes, and they're used automatically. So you'll never have to choose one of these pay codes, the system will pick it when it needs to, to use them. And they're specifically designed to track the flow of the money in these kinds of non cash transactions where we're moving the value of money from activities to facilities. But we're not actually like taking it out as cash and then putting it back in as cash. It's just the numbers that are moving around. So we attach them to these system pay codes. And that was kind of what I was referencing here. So we use the VSI system code to make these moves. If we're doing a refund finance, then we're using the system code to put the money into the refund finance account. But then we're using the refund finance pay code to take it out of that account. And this is kind of the the point that we wanted to say and I don't know, Brian, you probably have a clearer way of explaining why we don't want to do this double posting.
Brian Hatch 17:08
Right. So we I guess, what I always try to communicate, but sometimes it takes a couple tries. But so we take we put the money in that account, and we take it out automatically with that pay code. The that is one example, I think one of the few examples where you typically want to ignore the refund finance when it comes to your either your GL distribution reports or your GL interface if you're using that. But the idea is if usually, when an a refund finance, right finance is actually going to cut that check. And when they cut the check, that's when they're going to debit that refund account. So the idea is we don't want to send that debit to that refund account in the GL interface, and then also have finance Cut The Check and debit that same account again. Because I've definitely run it out a few times so that you know the Screen you're on right there, you just get refund finance on the debit side for the interface. And that basically leaves it in there for finance to handle as a part of their process.
Zach Malloch 18:12
You want to include it on the credit, so the money gets into the account. But then, because finance waits to cut the check there, usually a delay there. But in RecTrac, we don't have any process to come in and say which checks have been cut. So we just immediately relieve that account with the debit Brian was talking about. And if we included the debit coming across, then we're putting the money into the account and taking it out at the same time. So then when you go to actually cut the check, you're kind of double posting that that debit to that account, and then you're out of balance and things are bad.
Brian Hatch 18:45
Yes, I guess, please, since we're talking about it, the including paycode, right, you want to GL interface is just a great example, you typically what to include most pay codes or all pay codes is usually my default when I'm working with a customer. There, there might be some legitimate scenarios where you say you don't want to include some sort of correction. But one thing you wouldn't want to do, for example, I've run this fairly recently where a couple customers were trying to ignore that system, paycode they, I think it was part of it. Right? If you don't know what it is, and you feel like you don't want it right, I just want to see check cash and credit card. I don't want to see system for whatever that represents. But the problem is as soon as you start ignoring the VSI system, then you're not seeing some of our postings and you're immediately you're never going to balance right you're never going to see that internal movement and it's going to cause issues. So generally speaking, you want to almost use the rule include everything about refund finance, and there shouldn't be discrepancies. But if you start excluding things there's going to be I guess, but
Zach Malloch 19:48
yeah, they I guess the way to say it is kind of like all the stuff that we have there is definitely there for a reason. The way the accounts work, the way the pay codes work. There's a lot of things that are kind of baked into the logic on the back end of RecTrac. And if anybody's ever curious about it, I can point you to dB inquiry. And you can look at the SA GL account, table GL distribution. And then when we search for this, we do receipt number equals, and then we put in a receipt number. So this is 6262 or 67624. So this will show me all of the GL distribution that's happening for that particular receipt. Now, the thing that's interesting about this is that as soon as you put an item into your shopping cart, is when we start making transactions based on that item into these tables and everything. So if you put something in your cart, you kind of look at your GL distribution table for the next receipt number. So I'd be looking at number five, and probably there's, there shouldn't be anything in this receipt yet. But if I go put something in my cart, the next number that's going to be used is 67625. And we can kind of see the changes happening as we're putting something in the shopping cart as we're putting more stuff in the shopping cart as we go into the payment Screen as we're processing the payment or the refund or whatever. Not necessarily something that's going to really help with troubleshooting. But it's an interesting thing and helped me clarify some of my understandings about how accounting works with all of this. So I see there's more questions coming in. But I also see that we're already getting a little bit low on time. Were there any other areas you wanted to hit on? Brian, before we start responding to some more of these questions?
Brian Hatch 21:42
I'm looking through my notes right now. I guess I'm good with a question here.
Zach Malloch 21:48
Okay. Have you got any of those curated ready to tee up Cullen?
Cullen Barber 21:56
I do, Colleen asked. So should the refund apply balance amount equal to credit aging balance report balance? So essentially, there's the credit aging balance report. Does that basically equal what our control account balance should be?
Zach Malloch 22:20
Well, not the control account, but the refund apply? Yeah, there that should be tied together?
Cullen Barber 22:27
Yep. Okay, thank you. Yep.
Zach Malloch 22:29
And, you know, it does depend on time for Brian, I don't I'd let you respond to that first, I guess.
Brian Hatch 22:37
Yeah, I mean, I guess that that's exactly what should happen, you should be able to, if you have a specific refund apply down on this Screen here. That should be your, your payables or whatever the liability, I guess, but that you should be able to run a GL report for that account, if everything has been set up correctly from day one. And whatever that number is, should match the trial balance report for credits. Again, in a perfect world, that's really what should happen, I've once you muddy that, when again, once those are all the same, or once there's any kind of change halfway through those types of things, then all of a sudden, it's not going to so it really, it really depends. But that's that's what should happen.
Zach Malloch 23:17
And it also I was going to say that, it becomes very, very important to match up your your parameters for running your reports. So if you're running your credit balance aging report, then there's some pieces in that they're going to default to include everything. So you when you run your GL distribution report, and you want to run it for basically the with the entirety of the time that you guys have been using RecTrac so that you're including all the debits and all the credits and getting that net at the end of it. And then theoretically, yeah, that should match your your credit balance control account. Brian, as Brian mentioned, though, is there, especially for people who have a long history with Vermont systems and going through different versions and everything like that, or potentially running into different errors or changing the procedures that you were doing at previous points. There are certainly variances that can be introduced in those and they can, they can be kind of problematic to to identify. But
Brian Hatch 24:13
if you if you run into that case, right, I guess the once you're gonna find the difference, you could always do some sort of miscellaneous posting at some point. And you know, as long as the difference isn't changing, right, and you feel like it's good going forward. I've definitely worked with customers that have decided to do like a miscellaneous posting to get them to match. So that way going forward, they would have that. Have that be the case. So
Zach Malloch 24:35
Yeah, and I did see a real quick question about this Screen. And Casey or Casi notice that I these are the only required fields in this financial info Screen. And she's asking if we needed anything else well unearned you're only going to use on earned if this is set to receivables and you're doing accrual credit books are very specific Back to golf courses. And a lot of people aren't using those, you know, unlike us gift Certificate GL codes, most likely, you're going to be doing this just on the way that you set up your, your general your gift Certificate Service Item and the fees attached to that. So these are definitely the required fields, which is why they're red, we have to have these four system functions to work. And the rest of them are kind of optional. And cost centers are an optional piece that you're going to see next to virtually every GL Code in the entire system. It's just another way to add another piece of information so that we can identify the things more directly. And so maybe we have this GL Code for everything that's happening in refund finance, but then we make it specific to well, this is for facilities or this is for parks or this is for recreation, and then we get that extra tag that shows us more specific specificity about what's going on. I see a couple other bounced over here a couple
Cullen Barber 25:54
More questions that came in. When it's maybe not directly a control account, but more of a just an accounting. If with facility rentals when using the firm, tentative or hold statuses, does that affect the GL at all? If payments are made, or not made?
Brian Hatch 26:12
It does not. The status is kind of an internal thing that you can report on and the jails are still going to be the same regardless.
Cullen Barber 26:20
Great, thank you.
Zach Malloch 26:21
Yep.
Cullen Barber 26:26
Let's see. Denise asked how do credits on account that should be hitting revenue get routed to the control? So if a credit it's on account, when I guess if it's paying something off, how does that get routed? Through the control account? So if you're using a credit, what does that look like, under control a control account standpoint, or we shouldn't apply?
Zach Malloch 26:52
It shouldn't necessarily be. So when Brian, I were testing this earlier there, there's different situations. And it really seems to be like if you're doing multiple module stuff, if you're doing if you're moving money between different General Ledger codes, and the like. You might then have the control account interacted, if you're just using credit to pay for something, you should just see the debit to the refund, apply GL Code. And once again, if it is the same as a control account, then you'll see that debit to the control account, but it's really the refund apply that's getting debited the credit balance control account for the household. And then you should just see the credit into whatever revenue it's going to. So we really shouldn't if these are different, really shouldn't see, control account posting, just based on using household credit.
Cullen Barber 27:42
Okay, now that answers Sharon's question to where do household credit bail to show up and that's in the refund apply GL account? Right?
Zach Malloch 27:51
Right. If you're looking for a general ledger entry to them, they're there. Otherwise, we do track them through like the trial balance report, and things of that nature, which might be a little easier to look at, because it's also showing you which households have the balances rather than just what the totals are.
Cullen Barber 28:09
Great this, Benjamin had a question as well, if I leave a credit on a household is that allocated to the credit book GL or some other one. And, again, it's the refund apply GL account. Right?
Zach Malloch 28:21
Right. So just to maybe give a quick clarity or clarification on that. Let's go to global sales.
That's a credit balance. That'd be awesome. I went too fast and I didn't see her right to my payment Screen. And then right from here, I'm just using my credit so that I can get to this sure the selections that you're making because it's really based. There we go. It's based on the Type of refund that you're performing. So if I choose a refund now, it's going to use whatever accounts I've got linked to that if I'm going to leave it as a credit on the household i I can't choose refund apply because there's already credit on the household that's what I'm trying to refund so doesn't make sure since to refund the credit to refund the credit. So I have to choose between refund finance refund now and refund void and so based on what I'm selecting here, it's going to choose the other accounts and pay codes that it's using in the system appropriately. So just to add a little bit to that one.
Cullen Barber 29:47
Okay, Connie had a question. Maybe a little specific to their organization, but she says their control account does have a balance. We have a different GL account for the control account and refund apply. We we combine our transfers and refund finance into that into a 25 9000 a GL account. Could this be why our control account has a balance? And my gut says no, it sounds like you're set up separately, there might must be a different reason for your control account to have a balance.
Zach Malloch 30:20
Yeah. I would think that that would be something we'd need to start looking at the the actual transactions that are occurring, like Have you always had those separate accounts? Or was it something where maybe they started as one account, and then you decided to split them out? Like all those things could definitely make or can affect the results? And of course, also, have you migrated from previous previous version of RecTrac? Up to this one? Or were you newly installed on RecTrac 3.1? I see that you say that they're always separate accounts. So yeah, it would be probably getting into some of the detail and trying to find which transactions left the balance, and then we could start researching those transactions specifically. But, but kind of like Brian had mentioned, too, is if you're if you're running the reports consistently, and you're seeing the same exact balance that's like your $5 over and it's always that same $5 over, then we'd have resources where or we'd have options, we could make a posting to write off that $5 credit or just make it so it doesn't show up. And the idea that it's stable, that it's not changing, or increasing or decreasing, gives us that option to some degree. Anything that you would add to that, Brian,
Brian Hatch 31:37
let's definitely done that before, or I'll schedule reports for a few weeks or a few months depending on what we're troubleshooting. And if it stays constant, then we know it's not an ongoing issue, and we can some point choose to address it.
Zach Malloch 31:50
Exactly.
Cullen Barber 31:53
That. Let's see, we've got Rachel has a good question. I wanted to make sure of something I know every facility is different. But I want to make sure our procedures are properly refunding. You can you choose refund finance when a patron paid us in cash or cheque? So you could write there's no reason why you wouldn't be able to do that. You would choose refund now the patron pays us with a credit card physically in person. Typically, Yes, yep, you would choose refund apply when a patron registers online? Well, there's a lot of options there. You use, depending on your business rules and your permissions, you can do a lot with refunds, right? You know, it's really your policies, you know, typically, if somebody pays their credit card, you're gonna want to refund them with the credit card. And even if it was done online, depending on your credit card interface, you could still refund them from within the office to their credit card. So it just kind of depends. You know, you can allow patrons online to actually refund themselves in 3.1, so they could, you know, choose to apply it or you could force them to or have them refund it to their credit card. So, so lots of options there, you should be able to kind of define it the way you want to based on your business practices.
Zach Malloch 33:16
Yeah, the way that I usually say it too, is that like if the, if the thing is actually still in the cash drawer, like you took a $500 cash payment, and then they come in, they cancel, if you have $500 of cash in your drawer and it's within your policies to give it back to the customer, then I would do a refund now for cash and like most concession stands will do refund. Now if you need to get money back. Just as long as you have enough money in the register with checks, you don't want to have somebody write a check and then request a refund get cash back, but their check is in process of going to the bank and maybe it's going to bounce. So that's usually with checks, you're going to do it more the refund finance but you can also do refund finance for any purpose, you could have a long standing household credit and they decided to I'm not going to reinvest it. So I'd like to convert that to a refund finance and get the check cut and sent out to them and everything. So lots of different options, but it's really more driven by your policies then requirements or restrictions built into RecTrac. Alright, and I see that Connie did come in and said that it was a $0 balance until the end of 2020 and now it seems to continue to grow and that's actually I'm glad to see that it started the end of 2020 just because it's a much narrower scope we're not looking at all the history
Cullen Barber 34:36
it almost sounds like it's potential there's that the control account was used somewhere it wasn't this you know, almost like a revenue account. Right? Yeah, it could have been used somewhere so that's why it's growing we're seeing it grow as a credit maybe was accidentally linked, you know to a fee somewhere as a revenue GL
Brian Hatch 34:56
one troubleshooting thing if you go to fee management Zack you could always this is just So that's kind of good for we do it with new customers that are getting ready to kind of go live. But basically, you can do a little bit of an audit in here. So you could pick that control count, for example, and apply that to a filter in your revenue Field. And if something showed up there, that'd be kind of a red flag, right, though it's a good way to kind of confirm your, your setups and maybe find potential issues.
Zach Malloch 35:22
Yeah. So this is showing I don't have my this control account is not linked to any of my fees revenue code, so I'm not accidentally posting into it. When that happens, and I think I saw a question from Darla earlier this, this would be how you can verify that any of like, Fee Management would be a good place to go to potentially see what fees are linked to go to Show Settings, we're looking at this DataGrid. And then we have, well, there's a receivables, GL Code, there's a refund GL Code, we're middle GL codes, we can turn on all of these things. And then once again, that opens them up and gives us filters. And we can see if there are any values in any of these fields where there's not supposed to be. So I have a couple of things with some receivable setup. All right. Well, we're coming. We're definitely a little bit over and I want to be aware of everybody's time. So I'll just say real quick, we have been recording this, we will be posting it to the RecTrac RecChat portal by tomorrow. So if you do need to hop off, please feel free. And thank you for joining us. But if Cullen and Brian are game, we'll we'll stick around for a couple more minutes and pick a couple more answers or questions to try to answer.
Cullen Barber 36:32
Okay, yeah. Benjamin has another question. Is there an option coming to process refund now as part of an activity cancellation? So canceling, I guess, maybe all the entire class. So right now, I think there's no there's limited options apply? Or or finance? I believe?
Zach Malloch 36:54
Yeah, so this is not right. It's not where's that bulk cancellation? That's activity section management.
Cullen Barber 37:02
That sounds right.
Zach Malloch 37:12
Cancel section. So yeah, we're we are only giving you the option of refund apply our refund finance here. You know, if if people paid with cash? What would we do in an automated process with that cash? Like there's no way to really get it to them? So yeah, there are some limitations to what we can do here. So that seemed like that would answer the question Cullen?.
Cullen Barber 37:39
Yeah, I think so. Yep. Perfect. Okay. And let's see here. Or read through a few of these for remote yet, we can definitely share the RecChat Portal link. I'll do that in the in the chat here.
Zach Malloch 38:02
And actually, I I would prefer to ask answer Raymond's other question, Cullen, or Ramon. So this one is a really good one. And I think it's a it's an option. Or it's good. This is a this is a common thing. And it relates to that refund finance question we talked about before. So Ramon is asking what revenue reports do you recommend capture all the monthly revenues? We need to do this to post revenues from RecTrac into our financial system? And also which refund report do you recommend to capture the monthly refunds to customers, the refund report is needed to identify which revenue accounts need to be reduced in our financial system. And that last piece is really the part that I wanted to key in on. So the way that the cancellations occur is we're taking the money out of the program revenue, and we're putting it into this refund finance account. So when you're posting your money, anything that is posted into that refund finance account is all you need to worry about when you're cutting your checks and offsetting it, you don't need to make those offsetting transactions to the revenue for the refund because those offsetting transactions are being made as part of the transactional process. So when you're running that report, and speaking of the report, I would probably go with our our GL report. So GL distribution reports and refund or I'm sorry, a GL distribution summary report would be what I think most people would kind of look for. And you know, a lot of people are doing interfaces. So this is all automated. But if you don't have an interface, then choosing to GL distribution dynamic is one that we can do in summary mode, we'd switch that to summary. And then we would choose our users choose our GL criteria, our pay code criteria set our posting range so beginning of the month to the end of the month or the beginning of last month, to the end of last month. And then we could run this report and get the grand totals for each journal ledger account as a result of running this report. But that that piece about not needing to research the original revenue, as part of your refund process is exactly why the refund finance account exists in RecTrac. So that really should be your account payable account. So all of the money will show as debiting out of the revenues going into accounts payable. So whenever you cut the check, you're just doing it out of that one account. It's simple and straightforward.
Cullen Barber 40:43
Great. And then Jut had just one follow up to Rachel's questions. He wants to know, can you have a tiered cancellation fee set, so where a certain number of days out or longer would be a refund now, but if it's less than that time, it could be a refund apply? And I don't believe we have that Type of tiered calculation. When you get has, you know, the cart? Right?
Zach Malloch 41:09
Exactly, we all the criteria, and everything has to do with assessing the fees. And none of it has anything to do with how you can pay for those fees as well. Now that I'm thinking, I'm gonna go out on a limb just real quick here. And Brian, I know you're busy with some other stuff, if you need to hop off, please feel free to do that, too. And thank you very much for joining today. I've got something else selected, turn that off. So what you could theoretically do, and this is getting complicated, and it's really it's it has to do a little bit more with the timeline of when you would register for an activity. But because we have the additional sorry, because we have these payment. Now I'm thinking about it, and this is going to fall apart because of this doesn't control refunds. So we can specify what pay codes can be used to pay for certain items. So we could say that you're not allowed to pay with a check if you're within 14 days of registering. But the logic doesn't work the other way. So that was a negative negative thought that are not negative thought but an inaccurate thought it's not going to work for you Jut. Sorry about that
Cullen Barber 42:22
Sarah has a question when doing a bulk class cancellation, is there an option to surcharge each registered participant then applying credit to their household?
Zach Malloch 42:33
I don't
Cullen Barber 42:35
so can we do when you're doing a full class cancellation? Can you? surcharge everybody? There's no other reason for
Zach Malloch 42:44
class down. But yeah, that's the opposite. Really?
Cullen Barber 42:49
I guess unless there's a fee a cancellation fee. Tied somewhere at a higher level. Right?
Zach Malloch 42:57
Yeah, that's a good. Good point, Cullen. So we've got this. I mean, I could run through an activity or I told it to cancel. I don't actually want it to but that's okay.
I'm curious what would happen are actually I saw that my scheduler is not running right now. So I'm not actually going to be able to process that process. But I could be able to, I should be able to run a test real quick. And I can get in touch with Sarah to let her know if if we have a fee setup, if that automates that part of the process.
Cullen Barber 43:41
Yeah, Maureen posted, you know, maybe maybe create a fee reduction on a fee, or, or a cancellation Type fee somewhere?
Zach Malloch 43:49
Yeah, that's the i, if our logic works for seeing that, and I think it would, because the transaction is going to be a cancellation Type transaction. And if you have fees set up to charge at the time of cancellation, then theoretically it would. Oh, and Maureen says that they do have it set up and it seems like it works. So. So there's your answer. Thank you, Maureen very much.
Cullen Barber 44:19
Great, okay, tailor made one comment, we have an exclude Pay Code of credit book for everywhere, but the golf course. Because it cannot use a credit book credit to pay for anything except inventory at the golf course. So that might be an example.
Zach Malloch 44:36
Yeah, so that's our this is just a side thing on our fees. But so if it's easier just to say that specifically we don't do credit book or we don't allow credit book here. Like we all use scholarship as my example. So I'm going to exclude scholarship from being able to pay for this or I could say I want to include and put in another list but a lot of times it's easier to put the one thing that you're accepting And, and all of this can happen in bulk changes. So if you are looking for ways to, if you want to start updating your GL settings for some of your fees, if you want to try any of the exclusion things, or you want to just make sure that you're not sending information to wrong accounts, then using the Fee Management DataGrid. And getting into these options and deciding what fields you want to see, can can definitely help and be an investigative tool. And of course, you can also then export all of this as a comma delimited Excel spreadsheet, and then you can play around with it and slice and dice your information any way you want to.
Cullen Barber 45:38
Excellent. Well, looks like our question board is clear. And I've seen the attendees starting to slowly go down. So I know we went a little bit long. But thanks, everybody for joining us with good session. Who would have thought you know, the controller account could be so exciting, right? Good. Good topic, Brian and Zack. So thanks for bringing that up. And maybe we'll find another financial topic to talk about, you know, later on this year.
Zach Malloch 46:08
Nothing more thrilling than financial discussions Cullen!
Cullen Barber 46:10
Absolutely. For us accountants, right. We look we love this stuff. Okay. All right. Well, thanks, everybody, for joining us.
Zach Malloch 46:20
Absolutely. Thanks very much. We'll close this tomorrow and I'll talk to you all soon.