Let me enter/edit a payment date on an Invoice for manually reported transactions (e.g. Cash)

[thauburger]

Today, when I mark an Invoice as "Paid", the current date is used automatically as the recorded payment date - even when the Invoice is marked as paid via Cash/Check, and is manually reported.

Using the current date makes sense when Square processes the Invoice payment directly (e.g. credit card or ACH), since they know exactly when the transaction happened. But often when I accept payments in cash or check, I'm marking Invoices as paid manually after the fact when catching up on bookkeeping / end of the week or month accounting.

Forcing an automatic (and potentially inaccurate) payment date to be recorded on an Invoice for a manually reported transaction can create a variety of problems, including:

- Inaccurate reporting across Square when manually reported Invoice payments are credited to an after-the-fact day/month/year

- Difficulty finding / reviewing transactions

- Down stream impacts on things like tax reporting (e.g. I just had this happen for an Invoice I closed today (1/1/25), but the actual payment via check was right before our holiday closure in 2024, which could theoretically impact 1099 forms, etc.)

I think the minimal fix would be to allow users to enter a payment date at the time of marking an Invoice as paid manually via Cash or Check outside of Square.

The better experience would be to augment the above with the ability to edit manually reported Invoice payment dates.

At the very least, it seems like there should be a support process that allows you to have the Invoice payment date updated with the Square support team to correct issues manually. 

TL;DR; It makes sense to automatically record Invoice payment dates whenever Square processes the payment directly. When Invoice payments are manually reported, the user should have the ability to specify (and potentially edit) the Invoice payment date.

[RobynR]

Hey @thauburger, Currently, when you mark an invoice as paid in Square, the system records the payment date as the current date, regardless of when the payment was actually received. This applies to all payment methods, including cash and check.

We appreciate you sharing your business use case and why this feature would be valuable for you.

If you know of any fellow Seller Community members who would like to see this feature implemented, feel free to tag them in your post so they can share their thoughts as well. The more sellers chime in to the request, the more likely it is to catch our product team's attention.

[theshoppeon3rd]

I absolutely agree with this! I received a check for a large order in late December and just marked the invoice as paid today. Not being to manually enter the payment date throws off all of my accounting for both years. 

Can a square customer service agent change the date on the back end? 

[HTOC-bookstore]

I agree as well.  This is a major flaw when you aren't able to manually record the correct date and you can't edit it either.  It causes inaccurate accounting.

[TheRealChipA]

I want to add a caveat to this request.  I, and many other Square sellers, use automated third party apps (like Bookkeep or QuickBooks) to do our revenue accounting every day.  If it were suddenly possible to back-date transactions of any kind, this would cause even more accounting headaches because of the past being changed.  Once a day is closed it should be closed, from a strict accounting point of view.

I mention this only as a caution to the engineers who might be considering this.  While it might work perfectly well for some sellers, it would cause many more sellers infinite problems.  So, if this is going to be implemented, there should be two dates — one for the date the cash was received and another for the date it was posted to Square.  Otherwise you will be fixing one small problem and opening up a Pandora’s box for many other problems across the Square ecosystem.

[LTDBrewing]

I would also like this feature implemented.

[thauburger]

I agree with @TheRealChipA‘s general feedback on caution for any editing feature - Square shouldn’t let users just edit payment dates for all types of payments, and arbitrarily back date things. Any payments directly processed/accepted by Square (e.g. credit cards, ACH, PoS) have no need for editing, as Square “knows” the correct accounting date.

But general payment date editing is also not the feature request. The feature request is allowing me to edit (or at least specify) the correct transaction date at the time of recording *manually* reported Invoice payment types - specifically Cash/Check that are collected outside of Square’s ecosystem. Square assuming that the date I catch up on manual Invoice reporting (whether that’s a Monday after a weekend, or end of week, or end of month workflows) as the transaction date of that manual payment feels wrong from an acounting perspective, for the reporting and tax cases I bring up above.

If you wanted to avoid the complexity of “editing” transactions entirely, a basic fix could instead be to allow the user to select a transaction date at the time of going through the “Mark as Paid” UX. You could default that date to be “today”, but allow the user to edit/specify the correct date at the time of reporting, and then not allow any editing going forward.

General payment date editing is a Pandora’s box, agreed. But for those of us who use significant manual reporting of cash/check Invoice payments, Square assuming a transaction date for something that happened outside of Square, and then offering no way to specify the correct transaction date, is wrong in my opinion.

[rabidnerd]

I think this NEEDS to be an OPTION in the system, as like others, I am finding the need to backdate transactions when I use Square as a source of near authority and have a handful of other rare offline transactions to enter, but cant put the "real" date on them.

The warnings of the other could then simply be warnings to the end user about such side effects to integrations or specific accounting practices, as if this is an opt-in, they'd have nothing to worry about.