Accounting Module

[Audio] Welcome! In this video, we'll walk through the architectural design of the accounting module within our licensing system. While this isn't a full accounting system, it draws on familiar accounting concepts to provide a solid foundation and simplify integration with broader financial systems..

[Audio] At the heart of the module is the Account Transaction object. This object captures all financial activity related to licensing processes from the perspective of the licensee or applicant account. There are two main subtypes of account transactions: Debits & Credits..

[Audio] Debit transactions represent charges to the licensee's account. These include: Fees, which are charges for licensing services Refunds, or funds returned after being processed in the broader accounting system And Returns, which are similar to refunds, but are used for funds not yet processed outside the licensing system.

[Audio] Credit transactions represent additions to the licensee's account. These include: Payments, representing money received from the licensee, and adjustments, which are credits applied by the agency towards the licensee's account..

[Audio] Each Fee has an associated Fee Type. Currently, each fee type is defined to apply for a specific credential type. Fee types can have multiple Fee Amounts. Fee Amounts for a given fee type may vary based on criteria, such as license type or applicant category. If no criteria are defined, the fee amount would always be applied for that fee type. Lastly, each fee type can have a specific account, or revenue code, that can be defined for the fee type. This account would be used to categorize payments applied to fees of that type. Fees can be grouped based on the licensee, license or request that they are related to. If additional tracking is needed for some group of fees, the Invoice object may be helpful..

[Audio] Third-party processor transactions can be tracked using two behind-the-scenes, system objects - sys__payment and sys__paymentItem. Meanwhile, the licensing template uses its own Payment and Fee objects to manage and display transaction data. The system objects would link to the template objects for tracking continuity..

[Audio] The Allocation object is key to linking credits and debits. For example: When a payment is made for one or more fees, an allocation is created for each fee to show how much of the payment was applied. If a refund or return is issued, an allocation would link the refund to the original payment. The balance property for debit and credit transactions will automatically calculate based on how the transaction is allocated. Debit type would be set on an allocation if a debit is being allocated to a credit. Conversely, the credit type is tracked if a credit is being allocated to a debit. This ensures transparency and traceability across all financial interactions.</.

[Audio] To summarize, our accounting module is designed to track licensing-related financial transactions using familiar accounting structures for clarity and integration. By focusing on licensee-centric transactions, we maintain simplicity while enabling robust financial reporting and reconciliation. Thanks for watching and feel free to reach out with any further questions!.