Invoice process flow
A note should be added on when and how an invoice can be updated
Invoices can have one of the following statuses depending on where it is in the overall invoice-payment process: Draft, Pending, Open, Overdue, Cancelled, Payment in transit, and Paid. The figure below shows the flow of the invoice as it travels from one status to another.
- The invoice is created but is not yet sent to the client.
- The invoice is created and sent to the client.
- The invoice is sent to the client, but certain conditions are not met yet and payment cannot be processed. This can occur when a contractor has not completed the contract eligibility requirements set in place by the client. For example, a contractor failed to provide a certification requirement.
- The conditions are met, and the invoice is sent to the client.
- The client makes a payment on the invoice.
- The due date passes without payment.
- The client makes a payment on the invoice.
- The due date is modified so that the invoice is no longer overdue.
- The invoice is canceled by the client or the contractor.
- The invoice is marked as paid.
Invoice Events
Field Name | Definition |
---|---|
dueDate | Date by which the client is expected to pay the invoice. Used for informing the client, calculating late fees, determining invoice status, and setting expectations for payment timelines. |
events.openedAt | Timestamp of when the client first opened the invoice, indicating the invoice is in an open status that allows it to be paid. Used for tracking engagement, triggering reminders, and analyzing the invoice lifecycle. |
client.payDate | Date when the client intends to pay the invoice, as set by the client. Used for planning, payroll processing, and managing payment expectations. If set, the payDate takes precedence over the dueDate when identifying invoices to include in a payroll run. |
events.paidAt | Timestamp of when the invoice was successfully paid, also marking when payroll initiation occurs. Used for marking the invoice as paid, calculating payout timing, sending confirmation emails, and confirming execution of payment. |
events.estimatedDepositAt | Estimated date when the payout to the member is expected to be initiated. Used for informing the member about the expected payout date and triggering payout processing. |
events.depositedToPayoutPlatformAt | Timestamp of when the funds were successfully deposited into the payout platform's account. Used for tracking payout progress and reconciling transactions. |
events.depositedAt | Timestamp or date when the funds were successfully deposited into the member's payout account, with funds arriving in the wallet immediately and in the bank account in +1 business days. Used for marking payout as complete, updating member reputation, and informing about fund availability. |
events.paymentFailedAt | An array of timestamps recording when payment attempts failed. Used for tracking failures, notifying users, and triggering retries, providing a historical record of payment issues. |
events.paymentRetriedAt | An array of timestamps recording when payments were retried after failures. Used for tracking attempts, analyzing success rates, and understanding the resilience of the payment process. |
events.sentManuallyAt | An array of timestamps recording when invoices were manually sent by clicking "Send reminder" in the Wingspan app. Used for tracking manual sending activities, analyzing sending success, and ensuring proper communication. |
events.sentPayoutMightBeDelayedToClient | Timestamp when an email was sent to the client notifying them of a potential delay in payout. Emphasizes proactive communication in case of payout processing delays. |
events.sentPaymentConfirmationToMember | Timestamp of when the payment confirmation email was sent to the member, confirming that the invoice has been paid. Used to prevent duplicate emails and ensure clear communication about payment status. |
Updated 9 months ago