Backdating¶
What is contract backdating?¶
Creating a contract that started in the past is what’s known as backdating. This means that the invoices and line items associated with such a contract could be created immediately. This could lead to multiple invoices being finalized immediately if their end date has already occurred. Backdating should be performed with caution, since revenue documents that become finalized can affect downstream processes like billing or reporting. Although such a funciton can be dangerous, it is often necessary to start contracts months or years earlier.
Why is contract backdating important?¶
Backdating allows for a new history to be written. In combination with voiding existing data, changing or updating history is possible as well. A large part of the complexity within automating a business model is dealing with unforeseen variables. This can come in the form of customer requests or internal alignment. Backdating presents a path to deal with these cases since ratings and contracts can be backdated to allow for a different result. Thus backdating and how it works is crucial to understand since it can enable an operator to manage just about any changes thrown their way.
How to model contract backdating?¶
The modeling specifics of contract backdating are always the same, set the started_at of a contract to a date prior to now. The consequences of doing so are what introduce complexity. As mentioned before, if the backdate is prior to the last billing period the related revenue documents that are generated will immediately be finalized. Often this is the intended outcome of backdating, but this can lead to an unintended situation where a customer has overlapping contracts. Once again, this isn’t inherently bad but if done in ignorance this can lead to double charging a customer for the same product.
To safely model a contract backdate, it’s best to understand the desired end state. How many invoices are expected, what should the totals of these backdated invoices be, when should each invoice start and end, etc. Within bframe the best way to accomplish this is to experiment with a new branch. First create a new branch and then make the backdate directly to see what the invoices will look like. Repeat until satisfied with the output and finally apply it to the main branch.
Backdating with no active contracts¶
The first demonstration of backdating exhibits a fresh customer with no active contracts. This clean slate makes it straightforward to backdate a contract.
As of 6/1/2024, the customer “Leonprimer” has no contract in place. This user had a prior agreement with Wikipedia that they would not need to pay for the service. This agreement is still in place but the finance team would like visibility into how much usage is being given away for free.
customers.id |
customers.name |
customers.created_at |
contracts.durable_id |
contracts.started_at |
contracts.ended_at |
contracts.pricebook_id |
|---|---|---|---|---|---|---|
1011 |
Leonprimer |
2023-11-01 |
In this scenario, the customer’s created_at will determine the new contract’s backdate. Prior consumption data, in the form of events, has been logged and will be picked up if they occurred after the started_at.
customers.id |
customers.name |
customers.created_at |
contracts.durable_id |
contracts.started_at |
contracts.ended_at |
contracts.pricebook_id |
contracts.created_at |
|---|---|---|---|---|---|---|---|
1011 |
Leonprimer |
2023-11-01 |
Leonprimer_contract |
2023-11-01 00:00:00 |
2025-11-01 00:00:00 |
a |
2024-06-01 |
Once the contract has been created the modeling is complete. Revenue documents are then generated from November 2023 to the current time period, June 2024.
products.id |
products.name |
line_items.price |
line_items.quantity |
line_items.amount |
invoices.total |
invoices.invoice_delivery |
invoices.status |
invoices.contract_id |
invoices.started_at |
invoices.ended_at |
|---|---|---|---|---|---|---|---|---|---|---|
1 |
Updates |
0.10 |
11.0 |
1.1 |
127.89999999999999 |
ARREARS |
FINALIZED |
Leonprimer_contract |
2023-11-01 00:00:00 |
2023-12-01 00:00:00 |
2 |
Creates |
0.05 |
2536.0 |
126.8 |
127.89999999999999 |
ARREARS |
FINALIZED |
Leonprimer_contract |
2023-11-01 00:00:00 |
2023-12-01 00:00:00 |
1 |
Updates |
0.10 |
2.0 |
0.2 |
25.0 |
ARREARS |
FINALIZED |
Leonprimer_contract |
2023-12-01 00:00:00 |
2024-01-01 00:00:00 |
2 |
Creates |
0.05 |
496.0 |
24.8 |
25.0 |
ARREARS |
FINALIZED |
Leonprimer_contract |
2023-12-01 00:00:00 |
2024-01-01 00:00:00 |
1 |
Updates |
0.10 |
45.0 |
4.5 |
478.5 |
ARREARS |
FINALIZED |
Leonprimer_contract |
2024-01-01 00:00:00 |
2024-02-01 00:00:00 |
2 |
Creates |
0.05 |
9480.0 |
474.0 |
478.5 |
ARREARS |
FINALIZED |
Leonprimer_contract |
2024-01-01 00:00:00 |
2024-02-01 00:00:00 |
1 |
Updates |
0.10 |
18.0 |
1.8 |
201.4 |
ARREARS |
FINALIZED |
Leonprimer_contract |
2024-02-01 00:00:00 |
2024-03-01 00:00:00 |
2 |
Creates |
0.05 |
3992.0 |
199.6 |
201.4 |
ARREARS |
FINALIZED |
Leonprimer_contract |
2024-02-01 00:00:00 |
2024-03-01 00:00:00 |
1 |
Updates |
0.10 |
12.0 |
1.2 |
145.2 |
ARREARS |
FINALIZED |
Leonprimer_contract |
2024-03-01 00:00:00 |
2024-04-01 00:00:00 |
2 |
Creates |
0.05 |
2880.0 |
144.0 |
145.2 |
ARREARS |
FINALIZED |
Leonprimer_contract |
2024-03-01 00:00:00 |
2024-04-01 00:00:00 |
1 |
Updates |
0.10 |
13.0 |
1.3 |
156.9 |
ARREARS |
FINALIZED |
Leonprimer_contract |
2024-04-01 00:00:00 |
2024-05-01 00:00:00 |
2 |
Creates |
0.05 |
3112.0 |
155.6 |
156.9 |
ARREARS |
FINALIZED |
Leonprimer_contract |
2024-04-01 00:00:00 |
2024-05-01 00:00:00 |
1 |
Updates |
0.10 |
24.0 |
2.4 |
262.4 |
ARREARS |
DRAFT |
Leonprimer_contract |
2024-05-01 00:00:00 |
2024-06-01 00:00:00 |
2 |
Creates |
0.05 |
5200.0 |
260.0 |
262.4 |
ARREARS |
DRAFT |
Leonprimer_contract |
2024-05-01 00:00:00 |
2024-06-01 00:00:00 |
Backdating with active contracts¶
This example intends to show a messier state, where the customer already has an active contract and multiple finalized revenue documents.
As of 6/1/2024, the customer “Auntof6” raised that there could be an error in their invoices. This user, in April 2024, had asked their account executive for a customer support add-on and had negotiated for a discount in the “Updates” product. When reviewing the customer’s contract it is clear that the new negotiated pricing and product had never been added to the contract. It’s clear that a mistake has occurred and it must be rectified.
customers.id |
customers.name |
customers.created_at |
contracts.durable_id |
contracts.started_at |
contracts.ended_at |
contracts.pricebook_id |
contracts.version |
|---|---|---|---|---|---|---|---|
1323 |
Auntof6 |
2023-11-01 |
Auntof6_contract |
2023-11-01 08:22:48 |
2024-11-01 00:00:00 |
b |
0 |
products.id |
products.name |
line_items.price |
line_items.quantity |
line_items.amount |
invoices.total |
invoices.invoice_delivery |
invoices.status |
invoices.contract_id |
invoices.started_at |
invoices.ended_at |
|---|---|---|---|---|---|---|---|---|---|---|
1 |
Updates |
0.05 |
6192.0 |
309.6 |
309.6 |
ARREARS |
FINALIZED |
Auntof6_contract |
2024-04-01 00:00:00 |
2024-05-01 00:00:00 |
2 |
Creates |
0.04 |
0.0 |
0.0 |
309.6 |
ARREARS |
FINALIZED |
Auntof6_contract |
2024-04-01 00:00:00 |
2024-05-01 00:00:00 |
1 |
Updates |
0.05 |
38106.0 |
1905.3 |
1905.3 |
ARREARS |
DRAFT |
Auntof6_contract |
2024-05-01 00:00:00 |
2024-06-01 00:00:00 |
2 |
Creates |
0.04 |
0.0 |
0.0 |
1905.3 |
ARREARS |
DRAFT |
Auntof6_contract |
2024-05-01 00:00:00 |
2024-06-01 00:00:00 |
The desired end state would be invoices for the month of April and May that accurately reflect the deal that was agreed upon. This would result in pricing for the “Updates” product of $0.04 and a new customer support product that is charged in advanced. Given the incorrect revenue documents are finalized manual action must be taken to handle them. There are several paths to cleanly remedying this situation but this example will focus on the path of voiding the errant invoices and issuing new ones. Assuming “Auntof6” noticed the incorrect invoices prior to payment this example will exclude refunding the customer.
The first course of action is to backdate the ended_at of the original contract to the start of April 2024. This can be accomplished with a versioned edit. Then the invoices related to April should be voided. Now “Auntof6” has no recorded revenue documents past March which allows for a contract backdate to occur without any duplicate charges. The last step is creating the backdated contract with the discounted contract and the additional customer support add-on.
customers.id |
customers.name |
customers.created_at |
contracts.durable_id |
contracts.started_at |
contracts.ended_at |
contracts.pricebook_id |
contracts.version |
|---|---|---|---|---|---|---|---|
1323 |
Auntof6 |
2023-11-01 |
Auntof6_contract |
2023-11-01 00:00:00 |
2024-04-01 00:00:00 |
b |
1 |
1323 |
Auntof6 |
2023-11-01 |
backdate_contract |
2024-04-01 00:00:00 |
2024-11-01 00:00:00 |
b |
0 |
products.id |
products.name |
line_items.price |
line_items.quantity |
line_items.amount |
invoices.total |
invoices.invoice_delivery |
invoices.status |
invoices.contract_id |
invoices.started_at |
invoices.ended_at |
|---|---|---|---|---|---|---|---|---|---|---|
1 |
Updates |
0.04 |
6192.0 |
247.68 |
247.68 |
ARREARS |
FINALIZED |
backdate_contract |
2024-04-01 00:00:00 |
2024-05-01 00:00:00 |
2 |
Creates |
0.04 |
0.0 |
0.0 |
247.68 |
ARREARS |
FINALIZED |
backdate_contract |
2024-04-01 00:00:00 |
2024-05-01 00:00:00 |
1 |
Updates |
0.04 |
38106.0 |
1524.24 |
1524.24 |
ARREARS |
DRAFT |
backdate_contract |
2024-05-01 00:00:00 |
2024-06-01 00:00:00 |
2 |
Creates |
0.04 |
0.0 |
0.0 |
1524.24 |
ARREARS |
DRAFT |
backdate_contract |
2024-05-01 00:00:00 |
2024-06-01 00:00:00 |
7 |
Customer support fee |
1000.00 |
1.0 |
1000.0 |
1000.0 |
ADVANCED |
FINALIZED |
backdate_contract |
2024-05-01 00:00:00 |
2024-06-01 00:00:00 |
7 |
Customer support fee |
1000.00 |
1.0 |
1000.0 |
1000.0 |
ADVANCED |
DRAFT |
backdate_contract |
2024-06-01 00:00:00 |
2024-07-01 00:00:00 |