A financial close automation (FCA) system receives or retrieves account data from one or more enterprise resource planning products (ERPs). The FCA examines the balance sheet for a given account and determines whether the account is auto-certifiable, and whether the unknown balance is below a threshold amount. If the answer to either inquiry is no, the FCA generates a task for the general ledger owner to provide an explanation for the discrepancy. A task is the created for a manager to review the provided explanation. If the manager does not approve of the provided explanation, additional information may be required. Once the manager approves the provided explanation for the discrepancy, the account is certified. If the account is auto-certifiable and the unknown balance is below the threshold amount, the account is auto-certified.
|
1. A system, comprising:
a processor; and
a memory storing instructions that, when executed by the processor, cause the processor to:
receive accounting data for an account to be certified and one or more respective customizable threshold values associated with the account;
determine that a balance sheet for the account is not auto-certifiable based on an unknown balance of the account being above a threshold value of the one or more respective customizable threshold values;
cause a computing device associated with a general ledger owner of the account to display, via a graphical user interface (gui), a first task for the general ledger owner of the account based on the unknown balance of the account being above the threshold value, wherein the first task comprises providing an input indicative of a reason for the unknown balance being above the threshold value;
receive, via the gui, the input;
generate a second task for a manager based on the input, wherein the second task comprises providing an approval or a rejection of the reason for the unknown balance being above the threshold value;
receive, from the manager, the approval; and
mark the account as certified based on the approval.
7. A method, comprising:
receiving, from one or more enterprise resource planning products (ERPs), accounting data for an account to be certified and one or more respective customizable threshold values associated with the account;
determining, via a processor, that a balance sheet for the account is not auto-certifiable based on an unknown balance of the account being above a threshold value of the one or more respective customizable threshold values;
causing, via the processor, a computing device associated with a general ledger owner of the account to display, via a graphical user interface (gui), a first task for the general ledger owner of the account based on the unknown balance of the account being above the threshold value, wherein the first task comprises providing an input indicative of a reason for the unknown balance being above the threshold value;
receiving, via the gui, the input;
generating, via the processor, a second task for a manager based on the input, wherein the second task comprises providing an approval or a rejection of the reason for the unknown balance being above the threshold value;
receiving, from the manager, the approval; and
marking the account as certified based on the approval.
14. A non-transitory computer readable medium storing instructions that, when executed by a processor, causes the processor to perform operations comprising:
receiving accounting data for an account to be certified and one or more customizable threshold values;
determining that a balance sheet for the account is not auto-certifiable based on an unknown balance of the account being above a threshold value of the one or more customizable threshold values;
causing a first computing device associated with a general ledger owner of the account to display, via a first graphical user interface (gui), a first task for the general ledger owner of the account based on the unknown balance of the account being above the threshold value, wherein the first task comprises providing an input indicative of a reason for the unknown balance being above the threshold value;
receiving, via the first gui, the input;
causing a second computing device associated with a manager to display, via a second gui of the second computing device, a second task for the manager based on the input, wherein the second task comprises providing an approval or a rejection of the reason for the unknown balance being above the threshold value;
receiving, from the manager, the approval; and
marking the account as certified based on the approval.
2. The system of
3. The system of
4. The system of
5. The system of
6. The system of
receive an indication from the manager that the input accounting for the unknown balance is not approved; and
generate a third task to provide a supplemental input accounting for the unknown balance.
8. The method of
9. The method of
receiving an indication from the manager that the input accounting for the unknown balance is not approved; and
generating, via the processor, a third task to provide a supplemental input accounting for the unknown balance.
10. The method of
11. The method of
12. The method of
13. The method of
15. The non-transitory computer readable medium of
16. The non-transitory computer readable medium of
17. The non-transitory computer readable medium of
receive, via the second gui, an indication from the manager that the input accounting for the unknown balance is not approved; and
cause the second computing device associated with the manager to display, via the second gui, a third task for the manager based on the indication, wherein the third task comprises requesting a supplemental input from the general ledger owner accounting for the unknown balance.
18. The non-transitory computer readable medium of
19. The system of
20. The method of
|
The present application is a divisional of and claims priority to U.S. patent application Ser. No. 16/405,723 entitled “SYSTEMS AND METHOD FOR COMBINED ACCOUNT RECONCILIATION AND VARIANCE/FLUX ANALYSIS” filed May 7, 2019, which claims priority to and the benefit of U.S. Provisional Application 62/668,038, entitled “INTEGRATED TOOL AND APPLICATION SUPPORT,” filed May 7, 2018, the disclosure of which is incorporated herein by reference for all purposes.
The present disclosure relates generally to techniques for performing a financial close, and more specifically to techniques for account reconciliation and variance/flux analysis.
This section is intended to introduce the reader to various aspects of art that may be related to various aspects of the present disclosure, which are described and/or claimed below. This discussion is believed to be helpful in providing the reader with background information to facilitate a better understanding of the various aspects of the present disclosure. Accordingly, it should be understood that these statements are to be read in this light, and not as admissions of prior art.
Organizations, regardless of size, rely upon access to information technology (IT) and data and services for their continued operation and success. A respective organization's IT infrastructure may have associated hardware resources (e.g. computing devices, load balancers, firewalls, switches, etc.) and software resources (e.g. productivity software, database applications, custom applications, and so forth). Over time, more and more organizations have turned to cloud computing approaches to supplement or enhance their IT infrastructure solutions.
Cloud computing relates to the sharing of computing resources that are generally accessed via the Internet. In particular, a cloud computing infrastructure allows users, such as individuals and/or enterprises, to access a shared pool of computing resources, such as servers, storage devices, networks, applications, and/or other computing based services. By doing so, users are able to access computing resources on demand that are located at remote locations, which resources may be used to perform a variety computing functions (e.g., storing and/or processing large quantities of computing data). For enterprise and other organization users, cloud computing provides flexibility in accessing cloud computing resources without accruing large up-front costs, such as purchasing expensive network equipment or investing large amounts of time in establishing a private network infrastructure. Instead, by utilizing cloud computing resources, users are able redirect their resources to focus on their enterprise's core functions.
In modern communication networks, examples of cloud computing services a user may utilize include so-called infrastructure as a service (IaaS), software as a service (SaaS), and platform as a service (PaaS) technologies. IaaS is a model in which providers abstract away the complexity of hardware infrastructure and provide rapid, simplified provisioning of virtual servers and storage, giving enterprises access to computing capacity on demand. In such an approach, however, a user may be left to install and maintain platform components and applications. SaaS is a delivery model that provides software as a service rather than an end product. Instead of utilizing a local network or individual software installations, software is typically licensed on a subscription basis, hosted on a remote machine, and accessed by client customers as needed. For example, users are generally able to access a variety of enterprise and/or information technology (IT)-related software via a web browser. PaaS acts an extension of SaaS that goes beyond providing software services by offering customizability and expandability features to meet a user's needs. For example, PaaS can provide a cloud-based developmental platform for users to develop, modify, and/or customize applications and/or automating enterprise operations without maintaining network infrastructure and/or allocating computing resources normally associated with these functions.
Performing a financial close for an accounting period typically involves account reconciliation. Account reconciliation is the process of comparing records to make sure that the money being spent from an account matches the actual money that has left the account. After the financial close has been completed, a variance analysis and/or flux analysis may be performed. A variance analysis involves examining the difference between an expected or planned amount spent on a given item or group of items and the actual amount spent on the given item or group of items. A flux analysis involves examining fluctuations in money spent (in total, on a specific category of goods/services, on specific goods/services, etc.) from accounting period to accounting period. Typically, if a variance analysis and/or flux analysis is performed, the analysis takes place weeks, months, quarters, or even years after the financial close was performed. Accordingly, performing variance analysis and/or flux analysis may involve inquiries regarding transactions that are weeks old, months old, or older. As such, an individual's memory and/or documentation of the specific transaction in question may be lacking, resulting in variance analysis and/or flux analysis that is inefficient and sometimes incomplete.
A summary of certain embodiments disclosed herein is set forth below. It should be understood that these aspects are presented merely to provide the reader with a brief summary of these certain embodiments and that these aspects are not intended to limit the scope of this disclosure. Indeed, this disclosure may encompass a variety of aspects that may not be set forth below.
The disclosed subject matter includes techniques for performing a combined account reconciliation and variance/flux analysis via a financial close automation (FCA) system. Specifically, the FCA system receives or retrieves account data from one or more enterprise resource planning products (ERPs). The account data may include, for example, one or more balance sheets, one or more journals, prior and current account balances, recorded activity, and so forth. The FCA system examines the balance sheet for a given account and determines whether the account is auto-certifiable, and whether the unknown balance is below a threshold amount. If the answer to either inquiry is no, the FCA system generates a task for the general ledger owner to provide activities, documentation, and/or an explanation for the discrepancy. Once the general ledger owner provides activities, documentation, and/or an explanation for the discrepancy, a task is created for a manager to review the provided activities, documentation, and/or an explanation for the discrepancy. If the manager approves the provided activities, documentation, and/or an explanation for the discrepancy, the account is certified. If the manager does not approve the provided activities, documentation, and/or an explanation for the discrepancy, a new task is created, or the previous task is re-activated, for the general ledger owner to provide additional activities, documentation, and/or an explanation for the discrepancy. Once additional activities, documentation, and/or an explanation for the discrepancy are provided, a new task is created for the manager to review the new activities, documentation, and/or an explanation for the discrepancy. This loop repeats until the manager approves and the account is certified. If the account is auto-certifiable and the unknown balance is below the threshold amount, the account is auto-certified.
Various refinements of the features noted above may exist in relation to various aspects of the present disclosure. Further features may also be incorporated in these various aspects as well. These refinements and additional features may exist individually or in any combination. For instance, various features discussed below in relation to one or more of the illustrated embodiments may be incorporated into any of the above-described aspects of the present disclosure alone or in any combination. The brief summary presented above is intended only to familiarize the reader with certain aspects and contexts of embodiments of the present disclosure without limitation to the claimed subject matter.
Various aspects of this disclosure may be better understood upon reading the following detailed description and upon reference to the drawings in which:
One or more specific embodiments will be described below. In an effort to provide a concise description of these embodiments, not all features of an actual implementation are described in the specification. It should be appreciated that in the development of any such actual implementation, as in any engineering or design project, numerous implementation-specific decisions must be made to achieve the developers' specific goals, such as compliance with system-related and enterprise-related constraints, which may vary from one implementation to another. Moreover, it should be appreciated that such a development effort might be complex and time consuming, but would nevertheless be a routine undertaking of design, fabrication, and manufacture for those of ordinary skill having the benefit of this disclosure.
As used herein, the term “computing system” refers to an electronic computing device such as, but not limited to, a single computer, virtual machine, virtual container, host, server, laptop, and/or mobile device, or to a plurality of electronic computing devices working together to perform the function described as being performed on or by the computing system. As used herein, the term “medium” refers to one or more non-transitory, computer-readable physical media that together store the contents described as being stored thereon. Embodiments may include non-volatile secondary storage, read-only memory (ROM), and/or random-access memory (RAM). As used herein, the term “application” refers to one or more computing modules, programs, processes, workloads, threads and/or a set of computing instructions executed by a computing system. Example embodiments of an application include software modules, software objects, software instances and/or other types of executable code.
Performing a financial close for an accounting period typically includes account reconciliation and may involve variance analysis and/or flux analysis. Account reconciliation is the process of comparing records to make sure that the money being spent from an account matches the actual money that has left the account. The variance analysis and/or flux analysis is typically performed weeks, months, quarters, or even years after the financial close has been completed. A variance analysis involves examining the difference between an expected or planned amount spent on a given item or group of items and the actual amount spent on the given item or group of items. A flux analysis involves examining fluctuations in money spent (in general, on a specific category of goods/services, on specific goods/services, etc.) from accounting period to accounting period. Because the variance analysis and/or flux analysis is typically performed so long after the transactions in question, performing variance analysis and/or flux analysis may involve inquiries to individuals regarding transactions that are weeks old, months old, or even older. As such, the individual's memory and/or documentation of the specific transaction in question may be lacking, resulting in variance analysis and/or flux analysis that is inefficient and sometimes incomplete.
The disclosed subject matter includes techniques for performing a more streamlined financial close in which account reconciliation and variance/flux analysis are performed together, during the financial close. Specifically, a financial close automation (FCA) system receives or retrieves account data from one or more enterprise resource planning products (ERPs). The FCA system examines the balance sheet for a given account and determines whether the account is auto-certifiable, and whether the unknown balance is below a threshold amount. If the answer to either inquiry is no, the FCA system generates a task for the general ledger owner to provide an explanation for the discrepancy. A task is the created for a manager to review the provided explanation. If the manager does not approve of the provided explanation, additional information may be required. Once the manager approves the provided explanation for the discrepancy, the account is certified. If the account is auto-certifiable and the unknown balance is below the threshold amount, the account is auto-certified.
With the preceding in mind, the following figures relate to various types of generalized system architectures or configurations that may be employed to provide services to an organization in a multi-instance framework and on which the present approaches may be employed. Correspondingly, these system and platform examples may also relate to systems and platforms on which the techniques discussed herein may be implemented or otherwise utilized. Turning now to
For the illustrated embodiment,
In
To utilize computing resources within the platform 16, network operators may choose to configure the data centers 18 using a variety of computing infrastructures. In one embodiment, one or more of the data centers 18 are configured using a multi-tenant cloud architecture, such that one of the server instances 26 handles requests from and serves multiple customers. Data centers 18 with multi-tenant cloud architecture commingle and store data from multiple customers, where multiple customer instances are assigned to one of the virtual servers 26. In a multi-tenant cloud architecture, the particular virtual server 26 distinguishes between and segregates data and other information of the various customers. For example, a multi-tenant cloud architecture could assign a particular identifier for each customer in order to identify and segregate the data from each customer. Generally, implementing a multi-tenant cloud architecture may suffer from various drawbacks, such as a failure of a particular one of the server instances 26 causing outages for all customers allocated to the particular server instance.
In another embodiment, one or more of the data centers 18 are configured using a multi-instance cloud architecture to provide every customer its own unique customer instance or instances. For example, a multi-instance cloud architecture could provide each customer instance with its own dedicated application server and dedicated database server. In other examples, the multi-instance cloud architecture could deploy a single physical or virtual server 26 and/or other combinations of physical and/or virtual servers 26, such as one or more dedicated web servers, one or more dedicated application servers, and one or more database servers, for each customer instance. In a multi-instance cloud architecture, multiple customer instances could be installed on one or more respective hardware servers, where each customer instance is allocated certain portions of the physical server resources, such as computing memory, storage, and processing power. By doing so, each customer instance has its own unique software stack that provides the benefit of data isolation, relatively less downtime for customers to access the platform 16, and customer-driven upgrade schedules. An example of implementing a customer instance within a multi-instance cloud architecture will be discussed in more detail below with reference to
Although
As may be appreciated, the respective architectures and frameworks discussed with respect to
By way of background, it may be appreciated that the present approach may be implemented using one or more processor-based systems such as shown in
With this in mind, an example computer system may include some or all of the computer components depicted in
The one or more processors 202 may include one or more microprocessors capable of performing instructions stored in the memory 206. Additionally or alternatively, the one or more processors 202 may include application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), and/or other devices designed to perform some or all of the functions discussed herein without calling instructions from the memory 206.
With respect to other components, the one or more busses 204 include suitable electrical channels to provide data and/or power between the various components of the computing system 200. The memory 206 may include any tangible, non-transitory, and computer-readable storage media. Although shown as a single block in
With the preceding in mind,
In some cases, an enterprise may utilize the cloud infrastructure shown in
The top region 302 provides a summary. As shown, the top region 302 may include, for example, an indication of the projected close date 308, a percentage complete value 310, and a task summary 312. The projected close date 308 may display a projected or a scheduled close date and/or a number of days until the projected or scheduled close date. The percentage complete value 310 may display the percentage of completion toward close. The percentage complete may be based on time, tasks, weighted tasks, per-task time estimates, etc. In some embodiments, the percentage complete value 310 may also include a comparison of the current completion percentage to the planned completion percentage at the date in question. The task summary 312 may include an indication of the total number of tasks and an indication of the number of tasks that are completed, pending, overdue, follow-ups, etc. As shown, the task summary 312 may include a graphical representation of the breakdown of tasks into various categories (e.g., not yet started, pending, completed, overdue, etc.)
The middle region 304 includes one or more widgets, which may be customizable by the user. In the instant embodiment, the widgets may be displayed in a horizontal row. If the middle region 304 includes more widgets than can be displayed at one time, the user may scroll (e.g., using arrow buttons) to control which widgets are displayed by the middle region 304 at a given time. In the instant embodiment, the displayed widgets include a progress by function widget 316, and a reconciliation status widget 318. As shown, the progress by function widget 316 groups tasks by function and then displays the percentage complete for each group via a bar graph. In some embodiments, the bar for each group may be color coded to indicate whether the group is ahead of schedule, progressing as planned, experiencing a possible delay, and/or overdue, etc. The reconciliation status widget 318 includes a graphical representation (e.g., a pie chart) that displays the number of accounts to be closed and how many accounts fall into each status group (e.g., pending, pending approval, pending review, autoreconciled, reconciled, etc. It should be understood, however, that the widgets shown in
The middle region also includes a my work toolbar 322. The my work toolbar 322 displays the number of tasks assigned to a user that fall within specified categories. For example, the my work toolbar 322 may display the number of tasks assigned to the user that are overdue, the number of upcoming tasks, the number of rejected tasks, the number of failed journals, and the number of approvals. However, it should be understood, that the my work toolbar 322 may be customized to display the number of tasks assigned to the user that fall within the categories of their choosing.
The bottom region 306 includes a list of upcoming milestones 324 and a list of upcoming corporate tasks 326. The upcoming milestones list 324 displays a list of upcoming milestones, or tasks associated with milestones. Each listing includes data fields for task/milestone number, short description, status, and due date. The upcoming corporate tasks list 326 displays a list of upcoming tasks, with each listing including data fields for task number, short description, status, and due date. As shown, each list 324, 326, may not display a complete listing of the tasks/milestones that meet the given criteria. Accordingly, if the entire list is not displayed within the dashboard 300, the list may include a “view all” button that, when selected, allows the user to view all of the items on the list.
In some embodiments, the user may select the new task button or otherwise select a task to edit, causing the dashboard to open a window to create a new task or edit an existing task.
An overview widget 354 provides an overview of the selected task. In the instant embodiment, the overview widget provides account balances for an reconciliation and/or flux/variance analysis task. Specifically, the overview widget 354 displays a general ledger balance, a bank balance, and a variance in both reporting and local currency. However, it should be understood that the overview widget 354 may display different information for other types of tasks. A task status widget 356 t tracks the status of a task from draft to completion. In the embodiment shown in
Adjacent the task status widget 356, the task window 350 includes a due date widget 358. The due date widget 358 may identify the due date and/or the amount of time remaining until the due date. In some embodiments, the due date widget may include a graphical representation indicative of the amount of time left until the due date.
Below the task overview widget 354, the task status widget 356, and the task due date widget 358 is a row of tabs 360 and a bottom window 362. The tabs 360 control what is displayed within the bottom window 363. As shown, when a details tab is selected, the bottom window 362 displays data fields corresponding to general information about the selected task. For example, in the instant embodiment, when the details tab is selected, the bottom window displays data fields for currency, account type, entity, owner, short description, and various certification settings (e.g., whether the account is auto-certify exempt, the auto-certification threshold, if any, etc.). Other tabs within the row of tabs may include, for example, bank balance, bank support, general ledger support, flux analysis, child accounts, etc.
Adjacent the bottom window 362 are an activity stream widget 364 and a close assist widget 366. The activity stream widget 364 displays various activities associated with the task. For example, various people associated with the task (e.g., assignee, assignor, supervisor, etc.) may leave comments to each other in the activity stream widget 364, or otherwise have exchanges about the task. The activity stream widget 364 may also reflect documents or files attached or linked to the task, changes to the status of the task, actions performed toward completion of the task, etc. The close assist widget 366 may display information in order to help a user with tasks related to financial close. For example, in the instant embodiment, the close assist widget 366 displays related reconciliation tasks.
The FCA dashboard described in
In one implementation, combining account reconciliation and variance/flux analysis allows users of the FCA system to be able to view their own accounts and to add notes, activities, and supporting documents for unidentified balances as part of performing reconciliation activities. Concurrently or contemporaneously, users will be able to view the account balances over a period of time such as quarter-over-quarter (QoQ), year-over-year (YoY), year-to-date (YTD), and so forth, and will be able to perform variance/flux analysis (i.e., comparison to prior time periods, such as to identify trends, spikes, and so forth in the account activity) and capture the details, which can be viewed in the dashboard and/or via a report, such as by leadership, auditors, and so forth. This capability to be able to do variance/flux analysis and add commentary at the time of performing account reconciliation increases productivity and results in time savings.
In some embodiments, templates for different types of accounts (fixed assets, accruals, bank, etc.) may be created, allowing users to view and record information specific to those accounts. Users can also set the threshold which will automatically certify accounts that have unknown balances within the threshold, (e.g., a tolerance). Zero balance accounts can also be automatically certified. In one implementation, the process is integrated with FCA dashboard task management functionality and journal automation applications, which enable users to see if any journals specific to their accounts are pending to be posted. If so, they will wait for starting the reconciliation until journals are posted in the respective enterprise resource planning (ERP) package.
With this in mind,
In this embodiment, the FCA system may function as a normalizing top-layer that creates and/or maintains an underlying set of data commonly used by one or more of the ERPs. In this manner, the FCA dashboard may function as a single gateway by which a user interacts with or updates one or more ERPs without having to individually manipulate or interact with each ERP. Thus, the user may, via the FCA dashboard, request reports from one or more ERPs used by the user's organization, with the FCA system parsing the data and/or formatting communications for each respective ERP such that the user need only be familiar with the FCA dashboard commands and interface. Alternatively, work performed on the FCA dashboard, such as performing a reconciliation and variance/flux analysis on an account, may be performed without logging into or working in the ERP package itself. For example, if a user has multiple different ERP or multi-ERP instances in their landscape, the user can perform their work in the FCA dashboard and all the journal entries made using the FCA dashboard may be automatically posted in the ERP packages used by the client.
The received or retrieved account data may include, for example, one or more balance sheets, one or more journals, prior and current account balances, recorded activity, and so forth. The account data may be accessed by a cloud-platform provided with which the financial personnel interact, such as over a multi-instance architecture.
At decision 404, the balance sheet or sheets are analyzed to determine whether the balance sheet or sheets are auto-certifiable. A determination may be made as to whether a balance sheet (BS) account is auto-certifiable based on the pulled account information. An account is determined to be auto-certifiable if it meets certain criteria set by the user or owner. For example, certain types of accounts may be designated as auto-certifiable, while other types of accounts, or specific accounts, may be exempt from auto-certification. Further, an account may be auto-certifiable if the total balance, the general ledger balance, the unknown balance, the total amount of activity, the flux, and/or the variance is below a set threshold value, or some other condition is met. If the balance sheet is auto-certifiable, the process 400 proceeds to block 406 and determines whether the unknown balance of the balance sheet is above or below a threshold value. If the balance sheet is not auto-certifiable, the process 400 proceeds to block 408 and generates a task for the general ledger owner or owners to provide an explanation and/or documentation for unknown balances and/or variances. For example, a task may be displayed within the task list window of the general ledger owner's dashboard. Upon selection of the task, the task window may be updated to prompt the general ledger owner to provide activities, explanation, and/or documentation for any flagged unknown balances and/or variances. As previously described, the FCA dashboard may allow a user to attach or link one or more documents to a task.
At block 410, a task is generated for a manager to review the activities, explanation, and/or documentation provided by the general ledger owner. For example, a task may be displayed within the task list window of the manager's dashboard. Upon selection of the task, the task details window may be updated to prompt the manager to review the activities, explanation, and/or documentation for any flagged unknown balances and/or variances provided by the general ledger owner. The manager may decide whether or not to approve the activities, explanation, and/or documentation as justifying the flagged unknown balances.
At decision 412, if the manager does not approve the activities, explanation, and/or documentation as justifying the flagged unknown balances, the process returns to block 408 and requests additional activities, explanation, and/or documentation from the general ledger owner to justify the flagged unknown balances. In some embodiments, a new task for the general ledger owner may be created. In other embodiments, the previous task requesting activities, explanation, and/or documentation may be reactivated such that the task appears on the general ledger owner's task list. If new activities, explanation, and/or documentation from the general ledger owner to justify the flagged unknown balances are provided by the ledger owner, the process returns to block 410 and generates a task for the manager to review the activities, explanation, and/or documentation provided by the general ledger owner. The loop of blocks 408, 410, and 412 may repeat as needed until the activities, explanation, and/or documentation provided by the general ledger owner are approved by the manager. Once the manager approves of the activities, explanation, and/or documentation provided by the general ledger owner, the process 400 proceeds to block 414 and certifies the accounts. The certification may be an explicit certification (e.g., an additional input by the manager, an additional task, etc.), or the certification may be implied based upon the approval of the activities, explanation, and/or documentation. Once the accounts have been certified, the process marks the accounts in the FCA system as certified (block 416).
Returning to block 406, if an unknown balance for an account is above a threshold value, the process proceeds to block 408 and generates a task for the general ledger owner or owners to provide activities, an explanation, and/or documentation for unknown balances. The process then enters the loop of blocks 408, 410, and 412 previously described until the manager approves of the provided activities, an explanation, and/or documentation for unknown balances. If the unknown balance for an account is below the threshold value, the process proceeds to block 418 and auto-certifies the account or accounts. Once the accounts have been certified, the process marks the accounts in the FCA system as certified (block 416).
The disclosed subject matter includes techniques for performing a combined account reconciliation and variance/flux analysis via a financial close automation (FCA) system. Specifically, the FCA system receives or retrieves account data from one or more enterprise resource planning products (ERPs). The account data may include, for example, one or more balance sheets, one or more journals, prior and current account balances, recorded activity, and so forth. The FCA system examines the balance sheet for a given account and determines whether the account is auto-certifiable, and whether the unknown balance is below a threshold amount. If the answer to either inquiry is no, the FCA system generates a task for the general ledger owner to provide activities, documentation, and/or an explanation for the discrepancy. Once the general ledger owner provides activities, documentation, and/or an explanation for the discrepancy, a task is created for a manager to review the provided activities, documentation, and/or an explanation for the discrepancy. If the manager approves the provided activities, documentation, and/or an explanation for the discrepancy, the account is certified. If the manager does not approve the provided activities, documentation, and/or an explanation for the discrepancy, a new task is created, or the previous task is re-activated for the general ledger owner to provide additional activities, documentation, and/or an explanation for the discrepancy. Once additional activities, documentation, and/or an explanation for the discrepancy are provided, a new task is created for the manager to review the new activities, documentation, and/or an explanation for the discrepancy. This loop repeats until the manager approves and the account is certified. If the account is auto-certifiable and the unknown balance is below the threshold amount, the account is auto-certified.
In this manner, a reviewer will be able to perform variance/flux analysis while reviewing account reconciliation. While doing reconciliation, accountants already know what happened in the current month within the given account, which facilitates addressing unidentified balances. In addition, integration with a Journal Entry Suite enables accountants to have visibility as to whether there are any ongoing manual adjustments for the account and, knowing this, accountants can delay reconciliation activity. Without the integration, the accountant may have to redo the reconciliation. In this manner, a reviewer will not only be able to review current account balances and reconciliation entries, but also compare the current time period with prior periods, so as to spot spikes, dips, trends, or other variance in the account balance or activity over time, resulting in a more streamlines and efficient financial close.
The specific embodiments described above have been shown by way of example, and it should be understood that these embodiments may be susceptible to various modifications and alternative forms. It should be further understood that the claims are not intended to be limited to the particular forms disclosed, but rather to cover all modifications, equivalents, and alternatives falling within the spirit and scope of this disclosure.
The techniques presented and claimed herein are referenced and applied to material objects and concrete examples of a practical nature that demonstrably improve the present technical field and, as such, are not abstract, intangible or purely theoretical. Further, if any claims appended to the end of this specification contain one or more elements designated as “means for [perform]ing [a function] . . . ” or “step for [perform]ing [a function] . . . ”, it is intended that such elements are to be interpreted under 35 U.S.C. 112(f). However, for any claims containing elements designated in any other manner, it is intended that such elements are not to be interpreted under 35 U.S.C. 112(f).
Jafari, Amir Vakili, Tayal, Ankur, Tobin, Jessica Lee, Espinosa, Ellen Frances
Patent | Priority | Assignee | Title |
Patent | Priority | Assignee | Title |
6609122, | Aug 01 2000 | BMC Software, Inc.; BMC SOFTWARE, INC ; MBC SOFTWARE | Navigation of view relationships in database system |
6678887, | Jul 11 2000 | BMC SOFTWARE, INC | Customizing business logic and data sources by modifying methods defined within an API |
6714915, | Nov 22 1999 | eBay Inc | System and method for project designing and developing a procurement and accounts payable system |
7028301, | Dec 08 2000 | BMC SOFTWARE, INC ; BMC Software | System and method for automatic workload characterization |
7062683, | Apr 22 2003 | BMC Software, Inc.; SIDELINGER, MR KEN | Two-phase root cause analysis |
7131037, | Jun 05 2002 | BMC SOFTWARE, INC | Method and system to correlate a specific alarm to one or more events to identify a possible cause of the alarm |
7170864, | Mar 08 2001 | BMC SOFTWARE, INC | System and method for WAP server management using a single console |
7350209, | Jun 29 2001 | BMC Software | System and method for application performance management |
7610512, | Jan 06 2006 | THE CONUNDRUM IP LLC | System and method for automated and assisted resolution of it incidents |
7617073, | Mar 01 2002 | BMC SOFTWARE, INC | System and method for assessing and indicating the health of components |
7689628, | May 19 2005 | BMC SOFTWARE, INC | Monitoring several distributed resource elements as a resource pool |
7783744, | Jun 03 2003 | BMC SOFTWARE, INC | Facilitating root cause analysis for abnormal behavior of systems in a networked environment |
7890802, | Jan 06 2006 | THE CONUNDRUM IP LLC | System and method for automated and assisted resolution of IT incidents |
7930396, | Jul 10 2000 | BMC Software, Inc. | System and method of enterprise systems and business impact management |
7945860, | May 14 2003 | MICRO FOCUS LLC | Systems and methods for managing conversations between information technology resources |
7966398, | Mar 30 2001 | BMC Software, Inc. | Synthetic transaction monitor with replay capability |
7983971, | Jan 26 2006 | Fannie Mae | Accounting system and method |
8035094, | Jun 17 2002 | Quest Metrology, LLC | Methods for measuring at least one physical characteristic of a component |
8051164, | Dec 14 2007 | BMC Software, Inc. | Impact propagation in a directed acyclic graph having restricted views |
8078508, | Jan 25 2008 | INTUIT INC. | Method and system for upgrading to an integrated financial product |
8204809, | Aug 27 2008 | Accenture Global Services Limited | Finance function high performance capability assessment |
8224683, | Jul 08 2003 | Hewlett Packard Enterprise Development LP | Information technology service request level of service monitor |
8266096, | Oct 24 2008 | BLADELOGIC, INC | Vendor portfolio management in support of vendor relationship management analysis, planning and evaluation |
8457928, | Mar 26 2010 | BMC SOFTWARE, INC | Automatic determination of dynamic threshold for accurate detection of abnormalities |
8478569, | Mar 26 2010 | BMC Software, Inc.; BMC SOFTWARE, INC | Auto adjustment of baseline on configuration change |
8674992, | Jun 24 2010 | BMC Software, Inc. | Spotlight graphs |
8689241, | Sep 30 2011 | BMC SOFTWARE, INC | Dynamic evocations for computer event management |
8743121, | Dec 23 2009 | BMC Software, Inc.; BMC SOFTWARE, INC | Smart impact views |
8887133, | Apr 28 2006 | BMC SOFTWARE, INC | Bi-directional communication between change management tool and implementation tools |
8983982, | Dec 22 2009 | BMC Software, Inc. | Mechanism for deprecating object oriented data |
9065783, | Aug 31 2006 | BMC Software, Inc. | Automated capacity provisioning method using historical performance data |
9122552, | Jun 29 2012 | BLADELOGIC, INC | Hybrid cloud infrastructures |
9239857, | Dec 21 2004 | BMC Software, Inc. | System and method for building business service model |
9508051, | Mar 15 2013 | BMC SOFTWARE, INC | Business development configuration |
9535674, | Dec 21 2012 | BMC SOFTWARE, INC | Application wrapping system and method |
9535737, | Jan 30 2015 | BLADELOGIC, INC. | Dynamic virtual port provisioning |
9557969, | Mar 28 2012 | BMC Software, Inc. | Automated blueprint assembly for assembling an application |
9792387, | Aug 31 2001 | BMC Software, Inc. | Service desk data transfer interface |
20050015362, | |||
20050044197, | |||
20050102212, | |||
20050216830, | |||
20060277084, | |||
20070021996, | |||
20070156495, | |||
20090048883, | |||
20090228377, | |||
20110029344, | |||
20110191214, | |||
20120023371, | |||
20120330699, | |||
20140279304, | |||
20140358745, | |||
20150026021, | |||
20150379061, | |||
20160127376, | |||
20160283880, | |||
20160328883, | |||
20160379158, | |||
20170249642, | |||
20170270603, |
Executed on | Assignor | Assignee | Conveyance | Frame | Reel | Doc |
Feb 18 2022 | ServiceNow, Inc. | (assignment on the face of the patent) | / |
Date | Maintenance Fee Events |
Feb 18 2022 | BIG: Entity status set to Undiscounted (note the period is included in the code). |
Date | Maintenance Schedule |
Apr 23 2027 | 4 years fee payment window open |
Oct 23 2027 | 6 months grace period start (w surcharge) |
Apr 23 2028 | patent expiry (for year 4) |
Apr 23 2030 | 2 years to revive unintentionally abandoned end. (for year 4) |
Apr 23 2031 | 8 years fee payment window open |
Oct 23 2031 | 6 months grace period start (w surcharge) |
Apr 23 2032 | patent expiry (for year 8) |
Apr 23 2034 | 2 years to revive unintentionally abandoned end. (for year 8) |
Apr 23 2035 | 12 years fee payment window open |
Oct 23 2035 | 6 months grace period start (w surcharge) |
Apr 23 2036 | patent expiry (for year 12) |
Apr 23 2038 | 2 years to revive unintentionally abandoned end. (for year 12) |