EditInvoice Effective Date
In an effort to continue to improve our products to support the needs of our station owners to get paid more quickly, it was necessary for us to make some very fundamental changes to how we handle invoice dates.
More and more of our clients are moving towards getting invoices out the door as soon as they can so that they can get paid more quickly. The way that we (and most of our competitors) approached “billing” was to provide a billing cycle that was either broadcast, calendar, weekly, etc. and based on this cycle, the billing was to be tied to the end date of these cycles (what we will refer to as the billing cycle boundary). This, of course, has a major flaw; you aren’t really able to bill out until this billing cycle boundary is reached (expired). This means that you could run three spots on the 2nd, select calendar billing (for example) almost as a defacto standard and then are forced to wait as many as 29 days before you could actually approve the invoice in order to begin the collection process. Yes, we did provide the ability to prematurely approve these (force the issue), but then you would suffer with issues related to reporting because things occurred outside of their billing cycle boundary.
This is a great example of “just because it’s always been done one way” doesn’t necessarily make it the right way. In nearly every industry that we can think of, it is the rule that payment can be expected at any point upon providing the service. Yes, there is the NET 30 (or the like) that adds on to this, but the clock can start ticking at the point that services are rendered and payment requested.
In order to correct many of the long standing shortcomings, we had to make changes deep within our product to support this ever growing desire (or, as we see it, need) to get billing out the door in a much more timely manner. To do this we needed to find a date that wasn’t a moving target that could be inadvertently affected by other factors such as “invoice corrections”. Out of all of the options that we could discern, the best choice was to use the “last dated item on the invoice”; what we now refer to as the invoice effective date. The only way that this date would change is if additional items were added to the invoice (after reversal and re-approval) or the billing cycle was changed (after the fact, forcing recreation of the invoice(s)). It appears to be the steadiest of targets given all of the factors available.
What this means is that we can clearly present when an invoice is ready to be approved, assisting you with getting paid more quickly.
However, this means that we needed to change several reports to reflect this since it is now possible that you could approve an invoice that ran (and finished) for the 2nd, on the 3rd and pay it on the 23rd, all before the completion of the specified “billing cycle boundary”. The reports only understood the billing cycle boundary and need to be modified to support the “effective invoice date” so that this invoice (and possible payment) would be reflected on the report prior to the completion of the “billing cycle boundary”.
As a side note, this is actually a change that has been a long time coming; little changes were done here and there that, over time, began to create a bit of confusion since it sort of worked one way but was reporting a slightly different way and was not consistent across the span of features. The recent changes was a more concerted push to get things to be more consistent and correct the issues that were discovered along the way.
This means that a lot of things that were working one way, unfortunately, now work a slightly different way. This was absolutely necessary in order to reach the ultimate goal of assisting the majority of our clients to have the ability to get paid more quickly.