Grouping Payments by Stripe Payout Batch for Accounting
Feature outline, reasoning, and recommendations
When Stripe Journal Entries are calculated, this feature gives an additional option to the user, as shown
in this screenshot. If they are using Stripe Custom and they are choosing to “Use Actual Fees”, this will
enable the next option: grouping Stripe Custom payments by the Stripe Payout Batch
Why do this?
Journal Entries representing your income are entered into your accounting system, and those entries
then must match the actual amount of money put into your bank account. When part of those
payments are done through a third-party system (aka Stripe), you have to reconcile the amounts in the
RGP Journal Entries with the actual amount paid by Stripe. This feature is to make it easier by generating
journal entries that reflect the actual amount received from Stripe, rather than the payments you
receive from customers on a particular day.
What if I still want to see payments or sales on the actual day they are made?
This change will only affect the journal entries created by RGP for use in your accounting system. You
still have access to all Sales reports in RGP to show you sales per day, etc.
Why only Stripe Custom? And Using Actual Fees?
For RGP to know the actual amounts paid by Stripe, we need to have Stripe give us the information as to
what they did when creating the actual payout batches, and we are using their actual fees as part of
that. RGP does not have access to Stripe’s payout information for Stripe Standard customers. Finding the
Stripe Payout Batch information is a new Stripe Custom feature as of RGP Windows version 133928.
So what are the exact changes in the Journal Entries?
For non-credit card (aka non-Stripe Custom) payments, no change is made. For all stripe custom
payments, those payments will be included on the day they are put into a payout batch by Stripe. This
means that the debit side of the Journal entry, rather than having the current generic stripe codes, will
have one entry per payout batch and the amount of that debit will be the amount of the payout batch,
making it very easy to reconcile with your bank statements.
What is the effect of the “as of date”? Why have it?
Although we recommend a new Stripe Custom account use this feature from the beginning, we know
that many of our customers who will find this feature desirable are already using the current system of
grouping payments solely by the date they are made in RGP. In order to convert to using the new
method, a changeover date is necessary. Stripe Custom payments made in RGP before the changeover
date will be put into that day’s Journal entry, using the current method. Stripe Custom payments made
on or after the changeover date will be included in a Journal entry as part of their payout batch, when it
is created. Since Stripe often takes three or four days to batch out, there will be a transitional period in
which only some or no Stripe Custom payments will be included in the Journal entries. For example, if
the changeover date is July 1st, stripe payments made on or before June 30th will be included in that
day’s Journal entry (old system), but starting on July 1st, only Stripe Custom payments batched out that
day that were also made on or after July 1st would be included. The July 1st Stripe Payout batch would
not be included, since the payments in it were already accounted for in previous (old method) batches.
Once the July 1st payments start getting batched out, it is likely that a ‘partial Payout batch’ entry will be
the first one to show up, since it would be the first payout batch including payments made on or after
the changeover date, but it could include earlier payments (which were already accounted for earlier).
Do I still get one Journal Entry per day?
Yes. The only difference is the criteria for which payments are included for that day, and the debit
entries for Stripe Custom. Rather than those debit entries grouping by date/utc date, they group by
Payout batch. (So if Stripe, for whatever reason, created multiple payout batches on one day, the
Journal Entry gets multiple Stripe Custom debits, one for each payout batch.)
What about Point of Sale invoices paid for with multiple types of payment? (aka Split method)
There is only one payment record for the invoice, and if it is split method, it is still marked as Stripe
Custom, assuming Stripe was one of the methods involved. This means that the whole payment (aka
invoice) is included on the Journal Entry containing that Stripe Payout batch. For example, if an invoice
was paid for with $5 in cash and $10 credit card (Stripe Custom) on July 1st, that $5 cash is not included
in the July 1st journal entry. The whole payment of $15 is batched out a few days later (say, July 4th)
when the Stripe custom part of the payment is included as part of its Stripe Payout batch. If this split
method is common in your gym, this may be important to note, since the cash/check part was likely
included in your bank deposit on the day it was made, but won’t be shown in the Journal Entry for that
day. Also, if it is very common, this is a factor to consider when deciding whether to use this option.
What if I use Stripe Custom and I don’t want to use this feature?
There is no requirement to use it! Just leave the checkbox unchecked (which is the default) and things
will continue with no change.
What if I want to change my transition date?
This can be done at any time, but if you change it, any Journal Entries which were already made would
need to be recreated. So if you start out at July 1st, then change to August 1st, all Journal Entries already
made on (and including) July 1st up to (and including) August 1st would have to be recreated. For this
reason, we recommend being certain of your transition date before beginning use of this feature.
What happens if RGP is missing Stripe Payout data or my payments don’t match it?
Then Journal entries will be incorrect, possibly not including payments that they should, etc. For this
reason, anyone using this feature should always use the new Stripe Payout Reconciliation reports first to
confirm that all payout batches and payments match for the days in question before creating the Journal
Entry. Otherwise, not only will you have to go back later to correct payment data, you then must
recreate the Journal Entries from those days as well.