I would not recommend changing dates on rev arrs (...
# arm
k
I would not recommend changing dates on rev arrs (mismatch between source transactions and rev arr = bad audit mojo). Here is what I usually recommend to my clients a) put revenue plan on hold when you determine a custom is insolvent b) create a bad debt reserve (see Answers ID 64404) c) when it is concluded the customer will not pay take the revenue plan off hold and create return authorization for the amount you cannot recognize and d) write off bad debt via journal and accept the payment to remove it from the aging
✔️ 2
s
this may be a dumb question but... CM's also create their own RAs right? why is it suggested to create a return auth instead? (asking as we don't currently use return authorizations here, but am open to introducing it if it means we're doing things the right way)
our user also mentioned "_maybe we just merge the CM RA and SO RA, and if it's 0 we don't need to change the dates"_ (again, i'm advising against changing of any dates lol)
k
Return Authorization is the approval step for CM. If you JUST use a CM think of it as applying a payment to a transaction without any approval. Again, bad audit mojo imo. Yes, merging the two in the end is a good step to do. You never want to change the dates. Essentially when you (audit) run system notes for revenue processes there should be no human users present there….
✔️ 1
s
makes sense.. i was confused on which records have RAs. i really need to train up on ARM!