Chapter 5: Payment reconciliation

Summary

The connection to your practice management system is one way, meaning Aiwyn can read your data, but we cannot change or update data in your system.

Because of this, payments made through Aiwyn must be reconciled in your practice management system.

Every day, you will receive payment files that contain payments made through Aiwyn, emailed to your firm's payment notification email recipient(s). 

Some practice management systems allow for the importation of your Aiwyn invoice payment file, while others may not and this may require you to manually reconcile payments. Additionally, there are some types of payments that cannot be imported, such as a non-invoice payment.

The daily file(s) you receive are customized based on your needs, your reconciliation processes, and your practice management system.

While this is the last chapter of the User Guide, it is arguably the most important one to read, re-read, and reference in the future.

Prefer to watch a video? 

Included in this article

• Payouts from Stripe
• Aiwyn payment identifier
• Posting Aiwyn payment to different invoice
• Payment without an invoice
• Example files and scenarios
  • Credit card invoice + late fee payment
  • ACH invoices payment
  • Withdraw from bank account instead of deposit
• Additional reading

Payouts from Stripe

After you have connected your bank account(s) to Stripe, you will no longer have direct interface or interaction with Stripe beyond receiving deposits or correcting bank account connection. Rather, Aiwyn interacts with Stripe on your firm's behalf. You will not have a Stripe login.

Your connection to Stripe is under Aiwyn. Think of Aiwyn as an umbrella and your bank account(s) fall under our main account with Stripe. This allows payments made through Aiwyn to be deposited to your bank.

Payments made through Aiwyn are deposited to your bank two (2) business days later. Stripe batches together all payments into a single daily deposit, only on weekdays. 

The payment method and time of day the payment is made affects when that payment is included in your payout from Stripe.

The cutoff time for ACH payments is 19:00 UTC which means payments made that day after 19:00 UTC are batched with the following business day's transactions. Whereas the cutoff time for Card payments is 23:59 UTC and payments made that day after then are batched with the following business day's transactions.

For more information and payout time examples, read the separate article Stripe Invoicing and Client Payouts

Aiwyn payment identifier

Payments made towards an invoice through Aiwyn are automatically identified by our system and we automatically update their balance we read based on this payment. Think of it as "pre-reconciling".

Aiwyn is also reading all of your receipts for all payments reconciled in your practice management system. Because of this, you must always reconcile an Aiwyn invoice payment with the Aiwyn payment identifier included on the invoice payment file.

Note: When you reconcile an Aiwyn invoice payment, you must include your Aiwyn payment identifier so that our system "ignores" the reconciliation entry.

Example Scenario:

A client has an invoice for $2,000. They make a $1,000 partial payment through Aiwyn towards that invoice. Automatically, aiwyn updates the remaining amount due to be $1,000.

The firm receives the payment export file and reconciles the $1,000 towards the invoice. But they forgot to include the Aiwyn payment identifier in the reference area of the practice management system for that client payment entry.

Aiwyn reads that $1,000 reconciliation as a "payment" because no Aiwyn identifier was in place and now when the client goes to the portal, the invoice is shown as "fully paid".

***

To avoid this scenario, it is critical to reconcile all Aiwyn invoice payments by including the Aiwyn payment identifier in the appropriate Reference section of the client payment record in the practice management system.

During implementation, Aiwyn will help to determine which payment reference area of your practice management system should include the Aiwyn payment identifier, so that our system will ignore payment reconciliation entries for payments made through Aiwyn. 

Posting Aiwyn payment to different invoice

While uncommon, your accounts receivable team may choose to post a payment made to an invoice through Aiwyn to a different invoice of the same or different client. 

You MUST contact support@aiwyn.ai in order to let us know to unplug the Aiwyn payment from the invoice that was originally paid through Aiwyn, before you allocate an Aiwyn payment to a different invoice.

Failure to do these steps will result in the original invoice paid through Aiwyn show as paid still.

Payment without an invoice

The Client Portal includes the feature to make a payment without an invoice. Generally, a client will use this option because they do not see the invoice they want to pay in their portal. Recurring payments (not AutoPay) are also considered a "payment without an invoice".

When a payment without an invoice is made, the client is required to enter a payment description note to complete the payment.

This note will pass through to the non-invoice payment file. The firm will need to reconcile this "non-invoice payment" to the invoice that the client may have referenced as applicable.

Do not include the Aiwyn payment identifier when reconciling a non-invoice Aiwyn payment to an invoice in your practice management system.

Payment file examples

Example scenario: Credit card invoice + late fee payment

On Monday morning May 1, a client made a total payment with their credit card for $1,133.00. For demonstration purposes, let's also pretend this was the only payment made through Aiwyn that day.

This single payment through Aiwyn included the following items:

• $1,000 paid to invoice 5001
• $100 paid to their late fee
• $33 paid for processing fee (swept from transaction and kept by Aiwyn to cover you firm's merchant fee rate for cards)

On Wednesday May 3 (two business days later), $1,100 was deposited into your bank account and two different reports were emailed to your payment notification recipient.

Posted_Invoice_Payments

Payments made to invoices can be imported if import tool is available in your practice management system

Posted_alt_Payments

Non-invoice payments or non-invoice objects such as late fees print on this report. Anything in the alt file must be manually reconciled as it typically contains data that cannot be imported.

Analyzing the data:

Let's look at a few items from the reports and break them down further.

Date of reports match date of deposits (by default)

• Your reports send and contain data for the payments that are deposited that day
• The morning you receive a deposit is the same morning you receive the daily report file(s) containing the payment data for that day's deposit(s)

Client number/invoice number

• We will always provide you with the client number for each payment and object in your reports
• If client paid an invoice, the invoice number is also always provided
• If the payment was a "non-invoice" payment, a payment "Note" is required and printed in your ALT file

Ref ("reference", or sometimes "check number")

• Posted invoice payment file typically contains only payments made through Aiwyn to invoices
• If payment file import tool is available in your practice management system, this is the file that would be imported daily (per bank account) to reconcile Aiwyn invoice payments
• Notice the AIW, this is your Aiwyn payment identifier. (Note CCH ProSystem uses 99999 in the check number field instead of AIW in reference field)

Aiwyn payment identifier: "AIW" (or 99999) prints for all invoice payments made through Aiwyn. But notice how the late fee does not have AIW, this is because no Aiwyn payment identifier should be used for anything that is not exclusively a payment made through Aiwyn towards an invoice.

• When reconciling the payment to an invoice in the practice management system, include the exact string in reference/check no. column so that our system ignores the reconciliation entry appropriately.
• Do not include the Aiwyn payment identifier when reconciling a non-invoice Aiwyn payment

Payment Ref: In addition to the Aiwyn payment identifier, the numbers are the unique payment code.

• Notice the first part of the code, 1000, is the same for both rows in each report. This is to show that one payment action was made, tying the two objects together despite them being on two reports
• In the second part of the code -100 and -101 show the unique items the payment paid off:
  • -100 paid the Invoice
  • -101 paid the Late Fee

Amount

• When looking at the overall reconciliation for the day, sum up the total amount of the invoice payment file's amount column
• Plus the total from the Amount column of the Alt file's
• This will exactly equal deposited amount in bank.
• $1,000 + $100 = $1,100 (Amount Deposited in Bank)

Notes

• Payments made to invoices can contain additional data you may find helpful but that might not be importable into your system (or tied to data)
• Non-invoice payments made through the system require a "payment description" which will pass to you into your ALT file as a "note" so that you can review the client's intention with their non-invoice payment

Example scenario: ACH invoices payment

On Monday morning on June 1, a client selected to pay two invoices at once using an ACH bank transfer. For demonstration purposes, let's also pretend this was the only payment made through aiwyn that day. We are also going to assume the merchant fee rate for ACH transactions is 0.8%.

This single, $3,000 client payment made through Aiwyn included the following items:

• Invoice 61001 ($1,000)
• Invoice 61002 ($2,000)
• Total Payment Amount through Portal $3,000

On Wednesday June 3, $2,976 was deposited into your bank account. 

That same morning, the following reports were emailed to your payment notification email recipient(s):

Posted_Invoice_Payments

Payments made to invoices can be imported if import tool is available in your practice management system

Transaction fee report

Transaction fees that were swept from the client payment and removed from the principle amount paid by the client.

Analyzing the data:

Let's look at a few items from the reports and break them down further.

Transaction fee report amount

• At 0.8%, a total of $24 was removed from the original $3,000 payment
• A single payment, represented by the Ref-ID, will show as one line in the transaction fee report, even though multiple Invoices were paid in the single payment action
• The fees in this report represent the ACH or other subject card fees not passed to client based on your firm's contract with aiwyn (the merchant services for ACH and cards respectively)

Transaction fee report client & payment detail columns

• The columns outlined in the table above are in the actual standard daily transaction fee report (though renamed here in the article for brevity)
• Enough details are provided to tie the fee swept from the transaction to the payment object(s) in the other file(s)
• Use the payment reference ID code to identify all of the line items that pertain to that single payment action (in this example, that is the 1100 code seen in each of the example reports)

How to reconcile it all together against the bank deposit

1. Sum up the total amount from the Posted Invoice Payments File
2. Sum up the total amount from the Posted Alt Payments File if also sent that day
3. Add Invoice Sum and Alt Sum together to equal Total Payment Amount
4. Sum up the total amount from the Transaction Fee File to equal Total Fee Amount
5. Total Payment Amount minus Total Fee Amount equals Total Deposit Amount

$3,000 - $24 = $2,976

Consider the total fee amount from the file as the cost of doing business that day, it's a general expense rather than something tied to clients. The payment invoice and Alt files are intended to be used in your practice management system to reconcile and balance the data sourced first in Aiwyn back into your system. Combined, these reports give you a daily read out of your deposits. 

Example scenario: Withdraw from bank account instead of deposit

You check the bank account in the morning of May 13 and see ($2,016.00) withdrawn from your bank account connected to Stripe. The merchant fee rate for ACH transactions is 0.8%.

The following reports are in your email:

Posted_Invoice_Payments

Total from all ACH related rows: -$2,000.00 (negative amount)

You would not include the two credit card rows in your calculation because those were deposited in separate payout.

Payment Ref 10199 (two invoices) was a single ACH payment that failed. You (and the client) have received notification from aiwyn that the payment has failed.

Transaction fee report

Transaction fees that were swept from the client payment and removed from the principle amount paid by the client.

Total Fees withheld from ACH transactions: $32.00

Total Fees refunded due to ACH payment returned: $48

-$48 + $32 = -$16

Analyzing the data:

Let's look at a few items from the reports and break them down further.

• Posted Invoice Payments total ACH payments is a negative amount (-$2,000)
• Transaction fees are withheld and consider negative amounts as well, while ACH failures will have their fees originally withheld refunded. Sum of report's amount is the total amount withheld (-$16)
• -2000 + -16 = -$2016.00
• Negative amounts on the Posted Invoice Payments file must be reversed/unapplied/unallocated from the invoice in your Practice Management System.
• When a payment made through aiwyn fails or is refunded, it will appear as demonstrated. The invoice in aiwyn will automatically flip back to unpaid and can be payable again through the portal. The report is your cue to revert those funds that were originally applied to the invoice.

Additional reading

In order to understand everything related to payments, payment files, transaction sweeps, refunds, and failures, it is important for you to also review the following articles:

• Payout timeline
• Transaction sweeps
• ACH blocks & disputes
• Payment receipt emails
• Refunds
• Third party paying services

Up Next: Payment Plans