An accounting data incremental calculation method and system based on monthly closing snapshots

Abstract

The application discloses a kind of accounting data increment calculation method and system based on monthly closing snapshot. End-of-month automatically generates closing voucher and stores the end-of-period balance snapshot of each subject;When inquiring the balance of the Nth month, only N-1 month closing vouchers and N month business vouchers are read, and the time consumption is proportional to the number of vouchers in the month;After historical voucher changes, automatically cascade to rebuild the closing vouchers of the affected months, and automatically terminate if the balance does not change;After batch importing historical vouchers, automatically link and cascade;When multi-month accounting is interrupted, automatically generate bridging closing vouchers to fill the gap.The application realizes constant performance of balance inquiry, zero manual maintenance of historical voucher changes, one-key connection of batch import and one-key recovery of interruption.

Description

Technical Field

[0001] This invention relates to the field of financial data processing technology, specifically to a method and system for calculating incremental accounting data based on monthly carry-over snapshots. Background Technology

[0002] Existing technical solutions and their defects Option A (Full traversal) Each query accumulates all vouchers from month 1 to the target month. Query latency worsens linearly with the number of vouchers; a query for 100,000 vouchers over 5 years can take tens of seconds. Option B (Balance Caching) The database stores the monthly balances in advance and can be read directly. The cache becomes invalid after historical credentials are changed; existing solutions either require manual recalculation or silently return expired data. Limitations of existing technologies in scenarios involving batch import and accounting gaps Scenario B: Bookkeeping Gaps (Several Consecutive Months Without Bookkeeping) Many small and medium-sized enterprises (SMEs) do not keep bookkeeping records on time every month. A common scenario is: bookkeeping is done normally from January to March, then suspended from April to August for various reasons, and bookkeeping resumes in September. In existing accounting software, when vouchers are entered in September, the system cannot automatically handle the gap from April to August—because there is no closing data from April to August, the correct opening balance cannot be obtained in September. Existing solutions typically require users to manually enter zero-amount vouchers for the gap period or perform empty closing operations month by month, adding a large amount of meaningless mechanical labor. In existing solutions based on snapshots and backtracking recalculation, when historical data changes, it is usually backtracked and recalculated to the current date to generate new balance data. This method generates a lot of duplicate calculations when the data chain is long. Moreover, such solutions generally lack automatic termination mechanisms after changes, interruption recovery mechanisms, and gap processing capabilities in scenarios where there are no accounting entries for several consecutive months, resulting in wasted computing resources or data gaps that cannot be automatically repaired.

[0003] The technical problem to be solved by the present invention Question 1: How can the time taken to query the balance be made unaffected by the cumulative number of vouchers in the accounting system, and achieve a constant query speed of O(number of vouchers in the current month)? Question 2: After historical vouchers are changed, how can we automatically maintain data consistency for all affected months without recalculating all data? Question 3: When importing vouchers from any historical month in batches, how can the data chain reconstruction for the affected months be automatically triggered? Question 4: When a company resumes bookkeeping after several consecutive months of non-compliance, how can the financial data for the missing months be automatically filled in so that newly entered vouchers can correctly obtain the opening balance? Summary of the Invention

[0004] Technical solution To address the aforementioned technical problems, this invention provides a method for calculating incremental accounting data based on monthly carry-over snapshots, comprising the following steps: Step S1, Month-end carry-over snapshot generation: At the end of each month, automatically traverse all business vouchers for the month, summarize the cumulative debit and credit amounts by accounting subject, calculate the ending balance of each subject, summarize the ending balance of each subject into a carry-over voucher record, and persistently store the carry-over voucher in the carry-over voucher storage unit. Step S2, Obtaining the Initial Balance: When it is necessary to query the account balance for month N, the carry-over voucher for month N-1 is read from the carry-over voucher storage unit, and the ending balance data of all accounts in it is extracted as the initial balance for month N. If there is no carry-over voucher for month N-1, the process is traced back to the most recent month L with a carry-over voucher, where L is less than N minus 1. The ending balance of month L is used as the basis for the initial balance, and carry-over vouchers are generated sequentially for each gap month between month L plus 1 and N minus 1. The ending balance of each account in the carry-over voucher for each gap month is exactly equal to the ending balance of the corresponding account in the carry-over voucher of the previous month. Since there are no business vouchers in the gap month, the initial balance is passed on unchanged to the end of the period. When N is the first month of the account set, the initial balance is zero. If the month L does not exist, the initial balance is zero. Step S3, Incremental Balance Calculation: Traverse all business vouchers in the Nth month, and calculate the debit and credit amounts of each account in the current month; combine the beginning balance obtained in step S2 with the calculated amount for the current month to calculate the ending balance of each account in the Nth month. Step S4, Change Detection and Marking: When an add, delete, or modify operation is detected on a business voucher in month M, all subsequent months from month M to the current accounting period are marked as pending reconstruction. Step S5, Cascaded Reconstruction: For each month in the state to be reconstructed, the reconstruction operation is performed month by month in ascending order. Each layer of reconstruction includes: reading the carry-over voucher of the previous month to obtain the beginning balance, traversing all business vouchers of the current month to calculate the transaction amount, generating a new carry-over voucher and overwriting the old carry-over voucher of the same month; when the ending balance after a certain layer of reconstruction is the same as before reconstruction, the subsequent months of that layer will not continue to be cascaded.

[0005] Furthermore, the carry-over voucher includes a voucher type marker, a month field, and a list of account balances. Each account balance record includes an account code, account name, cumulative debit amount, cumulative credit amount, ending balance direction identifier, and ending balance amount. Before the cascading reconstruction is initiated, all carry-over vouchers in the affected month set are marked as dirty data. The dirty data state is the specific implementation of the state to be reconstructed at the database level. During the layer-by-layer reconstruction process, after each month's reconstruction is completed, the version number of the carry-over voucher for that month is incremented by 1 and its dirty mark is cleared. The version number is only used to record the cumulative number of times the carry-over voucher for that month has been reconstructed. The cascading reconstruction chain automatically crosses the natural year boundary. The cascading reconstruction is executed with locking at the account set level, and only one cascading task is allowed to run at the same time in the same account set. A database trigger is set in the business voucher table to automatically generate a change event when INSERT, UPDATE, or DELETE operations are detected. After each layer of reconstruction, the balance change is written to the cascading reconstruction log table. The balance query operation only accesses one carry-over voucher for the (N-1)th month. The system records the business vouchers for month N and the current month. The number of database records involved in the query is the number of vouchers for month N plus one, and is not affected by the total number of business vouchers accumulated since the account set was started. After each layer of reconstruction, the snapshot of the ending balance before and after the reconstruction of that month is compared. If the ending balance of all accounts has not changed, the cascading reconstruction of subsequent months is automatically terminated, and all dirty data in the affected months that have not yet been reconstructed is cleared, while keeping the existing balance data of these months unchanged. When multiple business vouchers are imported into month M in a batch, the entire batch import operation is regarded as a single change event, and the range of affected months is determined by merging. Starting from the earliest affected month, a cascading reconstruction is performed layer by layer to traverse all subsequent months. Before generating the carry-forward voucher for month N, it checks whether there is a carry-forward voucher for month N-1. If not, it traces back to the most recent month L with a carry-forward voucher, where L is less than N minus 1, and sequentially generates carry-forward vouchers for each gap month from month L+1 to N-1. The ending balance of each account in the carry-forward voucher of each gap month is exactly equal to the ending balance of the corresponding account in the carry-forward voucher of the previous month.

[0006] This invention also provides an accounting data incremental calculation system based on monthly carry-over snapshots, comprising: The carry-forward voucher generation module is used to automatically traverse all business vouchers of the month at the end of each month, summarize the cumulative debit and credit amounts of each accounting subject, generate carry-forward vouchers containing snapshot data of the end-of-period balances of each subject for the month, and persistently store them in the carry-forward voucher storage unit. The balance query interface module is used to receive query requests for the target month N, read the carry-over vouchers of month N-1 from the carry-over voucher storage unit to obtain the beginning balance, traverse the business vouchers of month N to calculate the monthly transaction amount, and combine the beginning balance and transaction amount to calculate the ending balance of each account and return it. The voucher change detection module is used to capture the addition, deletion, and modification events of business vouchers, determine the starting month M of the change, and write all subsequent months from M to the current accounting period into the queue of months to be rebuilt. The cascading reconstruction scheduling module is used to mark all carry-over vouchers in the affected month set as dirty data. Then, starting from the earliest dirty data month, it performs reconstruction month by month in ascending order: read the carry-over vouchers of the previous month to obtain the opening balance, traverse the business vouchers of the current month to calculate the transaction amount, generate new carry-over vouchers to overwrite the old ones, increment their version number by 1 and clear the dirty mark; if the closing balance of a certain month is the same as before reconstruction, the current cascading reconstruction of this set of accounts is terminated. The cascading log recording module is used to record the triggering reason, affected month range, operation time and operator information for each cascading reconstruction operation; The gap filling module is used to check whether there is a carry-over voucher for month N-1 before generating the carry-over voucher for month N. If not, it traces back to the most recent month L with a carry-over voucher, where L is less than N minus 1. For each gap month between month L plus 1 and N minus 1, carry-over vouchers are generated sequentially. The ending balance of each account in the carry-over voucher of each gap month is exactly equal to the ending balance of the corresponding account in the carry-over voucher of the previous month. Since there are no business vouchers in the gap month, the beginning balance is passed on unchanged to the end of the period. After the gap filling is completed, the carry-over voucher for month N is generated.

[0007] Overall Architecture Phase 1 (Stable Period) - Snapshot-Driven Incremental Queries: At the end of each month, carry-over vouchers are automatically generated to store a snapshot of the account balances for the current month; when querying the balance for any month, only the carry-over vouchers of the previous month and the business vouchers of the current month are accessed; Phase Two (Change Period) – Cascade Reconstruction: After historical vouchers are changed, the affected months are automatically marked and the carry-over vouchers are reconstructed layer by layer in chronological order; Phase 3 (Transition Period) - Batch Import and Gap Filling: After batch importing historical vouchers, cascading transitions are automatically triggered; when a gap in accounting for multiple months is detected, bridging carry-forward vouchers are automatically generated to fill the gap.

[0008] Carryover snapshot generation mechanism At the end of each month, the process of generating closing vouchers is triggered. For each accounting subject used in the current month, first, all debit entries for that subject in the current month are summarized to obtain the total debit amount, and then all credit entries for that subject in the current month are summarized to obtain the total credit amount. Next, the ending balance of that subject in the previous month's closing voucher is read as the beginning balance. Finally, the ending balance of that subject is calculated by adding the total debit amount to the beginning balance and subtracting the total credit amount. After all subjects have been calculated, a closing voucher containing the ending balance of each subject is generated and persistently stored.

[0009] Incremental balance query mechanism When querying the account balance for month N, the process first reads the closing vouchers for month N-1, obtaining the ending balances of all accounts recorded therein as the beginning balances for month N. Then, iterates through all business vouchers for month N, calculating the debit and credit amounts for each account during the month. The beginning balances are then combined with the current month's transactions to calculate the ending balances for each account in month N, which are then returned. The entire process accesses only one closing voucher record and the business vouchers for month N, without accessing any business vouchers prior to month N-1. Therefore, the query time is positively correlated with the number of vouchers for the current month and is not affected by the total number of business vouchers accumulated in the accounting system.

[0010] Change triggers cascading reconstruction mechanism When business vouchers in month M undergo addition, deletion, or modification operations, the system first determines the month M in which the change occurred and the latest month C in the current accounting period. Then, it marks all carry-over vouchers from month M to month C as dirty data, i.e., sets the dirty data flag field `is_dirty` to true. Subsequently, starting from month M, the system performs reconstruction month by month in ascending order: it reads the reconstructed carry-over vouchers from the previous month to obtain the opening balance, iterates through the business vouchers of the current month to calculate the transaction amount, and calculates the new closing balance. If the new closing balance is different from the old closing balance, the new carry-over voucher overwrites the old one, the version number is incremented by 1, and the dirty data flag for that month is cleared, and reconstruction continues for the next month. If the new closing balance is the same as the old closing balance, the current cascading reconstruction is automatically terminated. Finally, the triggering reason for this cascading reconstruction, the range of affected months, and other information are written to the cascading reconstruction log.

[0011] Automatic continuation mechanism for batch importing historical vouchers When vouchers are imported in batches to historical month M, the system first identifies the earliest affected month M and the latest month C in the current accounting period. Then, it marks all carry-over vouchers from month M to month C as dirty data, setting the `is_dirty` field to true. Subsequently, a cascading rebuild is initiated, rebuilding layer by layer from month M to month C. The rebuilding logic for each layer is the same as the change-triggered cascading rebuild mechanism: it reads the carry-over vouchers rebuilt in the previous month to obtain the opening balance, iterates through the current month's business vouchers (including the newly imported vouchers) to calculate the transaction amount, generates new carry-over vouchers, increments the version number by 1, and clears the dirty data mark for that month. After the cascading rebuild is complete, the batch-imported financial data is automatically propagated to the current month, requiring no further manual operation from the user, and the accounting data remains consistent immediately.

[0012] Automatic compensation mechanism for gaps in cross-month accounting When a company resumes bookkeeping after several consecutive months of inactivity, the system automatically performs gap detection and remediation. Taking a scenario where bookkeeping is normal from January to March, suspended from April to August, and resumed in September as an example: When a user first enters vouchers in September to trigger month-end closing, the system checks the chain of carry-over vouchers prior to September. It finds carry-over vouchers for March but not for April, thus identifying the gap window from April to August. The system then generates bridging carry-over vouchers for each empty month within the gap window: it reads the carry-over vouchers from the previous month with existing vouchers. Since there are no business vouchers in the empty month, the current period's transaction amount is zero, and the ending balance equals the beginning balance—meaning all account balances are passed on as is. This generates a carry-over voucher for the empty month marked as automatically bridged. After gap remediation is complete, the system reads the August carry-over vouchers to obtain the beginning balance according to the normal month-end closing process, and combines this with the September business vouchers to generate the September carry-over voucher. During this process, the user does not need to enter any vouchers for the empty months, nor does they need to manually perform empty closing operations, and the remediation chain automatically crosses the year boundary.

[0013] Technical Effect Description Depends only on the previous layer Reconstructing the 60th month only accesses the carryover from the 59th month plus the 60th month vouchers, without going back to months 1-58. Automatic termination If the balance remains unchanged after a certain layer is rebuilt, the balance will also remain unchanged in subsequent months, and the cascading rebuild will automatically terminate. Seamless transition across years Cascaded links / gap compensation links automatically cross annual boundaries, regardless of the year. Dirty marking prevents crashes Before cascading, mark dirty data; after completion, clear the dirty data markers. After restarting, query records where the dirty data marker field is_dirty has a true value to directly locate breakpoints. Account-level segregation Only one cascaded task can be performed within the same account set at a time, while tasks can run in parallel across different account sets. Audit traceability Cascading logs only append and do not modify, while permanent records are automatically rebuilt each time. Batch import link Importing vouchers into any historical month automatically cascades the data, allowing for real-time data propagation. Automatic gap compensation When resuming bookkeeping after several months of inactivity, bridging transfer vouchers are automatically generated to fill the gaps.

[0014] Beneficial effects Query performance improvement The query time has been optimized from being related to the total number of vouchers to being related to the number of vouchers in the current month, resulting in a 100 to 1000-fold improvement in actual testing. Consistency Automatic Maintenance After historical vouchers are changed, zero manual operation is required; they are automatically cascaded and rebuilt. Minimize the reconstruction range Only the affected months are recalculated, plus automatic termination, resulting in a 90% reduction compared to a full recalculation. Audit trail The cause, scope of impact, and balance changes for each cascading rebuild are all recorded. High availability Dirty marking prevents crashes and enables automatic recovery and cascading rebuilding after system interruption. Batch import with zero operations After importing historical vouchers, there is no need for manual recalculation month by month; the process is automatic. One-click recovery of missing data When resuming accounting after several consecutive months of non-recording, there is no need to fill in blank vouchers; the process is automatically bridged. Attached Figure Description

[0015] Appendix Figure 6 open: Figure 1 The system architecture diagram provided for embodiments of the present invention; Figure 2 This is a flowchart of the normal month-end snapshot generation process provided in an embodiment of the present invention; Figure 3 A flowchart of incremental balance query provided in an embodiment of the present invention; Figure 4A flowchart of cascaded reconstruction provided for embodiments of the present invention; Figure 5 This is a flowchart illustrating the automatic connection process for batch importing historical vouchers provided in an embodiment of the present invention. Figure 6 The flowchart for automatic correction of accounting gaps provided in the embodiments of the present invention.

[0016] in: Figure 1 In the middle: 10 is the business voucher management module; 20 is the voucher change detection module; 30 is the carry-over voucher generation module; 40 is the balance query interface module; 50 is the cascade reconstruction scheduling module; 60 is the cascade log recording module; 70 is the carry-over voucher storage unit; 80 is the gap filling module; Figure 2 In the middle: 110 is the business voucher for the current month; 120 is the carry-forward voucher for the previous month; 130 is the summary of transactions; 140 is the calculation of the ending balance; 150 is the generation of the carry-forward voucher; Figure 3 In Chinese: 210 is the query request; 220 is the read of the previous month's carry-over vouchers; 230 is the traversal of the current month's vouchers; 240 is the calculation of the ending balance; 250 is the return of the query results. Figure 4 In the middle: 310, 320, 330, and 340 are the status nodes for the Mth month, the (M+1)th month, the (M+2)th month, and the (M+3)th month, respectively; 311, 321, 331, and 341 are the reconstruction processing nodes for the corresponding months, respectively. Figure 5 In the middle: 410 is the batch import module; 420 is the import start month; 430 and 440 are intermediate months; 450 is the current month; 460 is the cascade reconstruction scheduling module; Figure 6 In the middle: 510 to 518 are the month nodes from the 1st to the 9th month respectively; 610 is the gap detection and traceability module; 620 is the bridging carry-over generation module. Detailed Implementation

[0017] Example 1: Generating a normal month-end carryover snapshot Scenario: Launched in January 2025, with 10 vouchers in the first month; Summary: Bank deposits: debit 1 million / credit 750,000; management expenses: debit 50,000; main business revenue: credit 300,000. All figures at the beginning of the first month are 0. After calculation: the ending balance of bank deposits is 250,000 yuan (debit), the ending balance of management expenses is 50,000 yuan (debit), and the ending balance of main business revenue is 300,000 yuan (credit). Trial balance: The total debit balance at the end of the period is 300,000 yuan, which is equal to the total credit balance at the end of the period. Generate a carry-over voucher for January 2025 (version v1) and store it persistently.

[0018] Example 2: Incremental Balance Inquiry Scenario: The account has been running for 3 months, and the user is checking the balance for March; The method of this invention is as follows: read the February carryover voucher (1 database query) and traverse the March voucher (15 records), accessing a total of 16 records; Full traversal method: Traverse 10 records for January, 12 records for February, and 15 records for March, for a total of 37 records visited; When the accounting system has been in operation for 60 months and has accumulated 100,000 vouchers, this invention only accesses one carry-over voucher and about 200 vouchers for the current month, while a full traversal would require accessing all 100,000 records; performance improvement: 100-1000 times.

[0019] Example 3: Deletion of historical credentials triggers cascading reconstruction Scenario: The accounting system was in operation until June, and the user deleted voucher No. 15 in March (an entry for a bank deposit debit of 50,000 yuan). ① The detection module captures the deletion event and determines that M is March 2025 and C is June 2025; ② Mark the carry-over vouchers for each month [03, 04, 05, 06] as dirty data (is_dirty=true); ③ Rebuild March: Read the February carryover voucher to obtain the beginning balance, combine it with the remaining vouchers in March to calculate, the ending balance of bank deposits changes from 500,000 to 450,000, generate a new carryover voucher, change the version number from v1 to v2, and clear the dirty data mark for this month. ④ Rebuild April: Read the new carry-forward vouchers from March to obtain the beginning balance, combine them with the vouchers from April to calculate, the ending balance changes, a new carry-forward voucher is generated, the version number changes from v1 to v2, and the dirty data markers for this month are cleared; ⑤ Reconstruct May and June using the same logic, remove dirty data markers from all months, and write the data to the audit log; User experience: After deleting an old voucher from 3 months ago, opening the current month's ledger shows the correct balance after cascading reconstruction. Zero manual intervention required.

[0020] Example 4: Automatic Termination of Cascade Scenario: A loan voucher for 100,000 yuan was entered in May 2025. Upon verification, it was discovered that the loan actually occurred in June. The user deleted the May loan voucher and created a new loan voucher for the same amount in June. [05, 06] are marked as dirty data; May Reconstruction: Read the April carryover voucher to obtain the beginning balance, combine it with the remaining vouchers in May (the 100,000 loan has been deleted) to calculate, the ending balance of accounts such as bank deposits has changed, a new carryover voucher is generated, the version number is incremented by 1, and the dirty data mark for this month is cleared, the balance changes, and reconstruction continues for the next month; June Reconstruction: Read the new carry-over vouchers from May to obtain the opening balance (100,000 less than the old opening balance), combine with the vouchers from June (including the new loan of 100,000) to calculate that the ending balance of bank deposits and other accounts is completely consistent with the old carry-over, automatically terminate the cascading reconstruction, clear the dirty data mark for June, and write it to the audit log. Explanation: The loan of 100,000 was moved from May to June. At the beginning of June, the 100,000 shortfall plus the 100,000 new loan exactly offset each other. The ending balance at the end of June is consistent before and after the cascading, which meets the conditions for automatic termination.

[0021] Example 5: Cross-Year Cascading Scenario: Modifying the amount of a voucher dated November 2024 in January 2025; The cascaded links will be installed in November 2024, December 2024, and January 2025, respectively. Carry-forward snapshots use months as the smallest unit, without distinguishing between years, and the logic across years is completely consistent.

[0022] Example 6: Crash Recovery (Pure Dirty Marking Mechanism) Scenario: A user modified a voucher from March in June, triggering a cascading rebuild. The system executes the following steps: Before reconstruction: Affected months: March, April, May, and June. All carry-over vouchers for the affected months are marked as dirty data, i.e., the `is_dirty` field is set to true. The current version numbers for each month are v3, v3, v3, and v3 respectively. These version numbers are only used to record the cumulative number of times each month has been reconstructed and are not used as the basis for determining whether to reconstruct. Reconstruction process: March was reconstructed layer by layer, changing the version number from v3 to v4, and clearing the dirty data markers for that month; April was reconstructed, changing the version number from v3 to v4, and clearing the dirty data markers for that month; the server lost power while May was being reconstructed. Status after reboot: March: Version v4, dirty data marked as false, reconstruction complete. April: Version v4, dirty data marked as false, reconstruction complete. May: Version v3, dirty data marked as true, rebuild not executed. June: Version v3, dirty data marked as true, rebuild not executed. Recovery logic: ① After the system restarts, scan the carryover voucher storage unit and query records where the dirty data flag field is_dirty has a true value. ② Find the earliest month of the dirty data, which is May. ③ Starting from May, rebuild all months with dirty data in chronological order: increment the version number of May by 1 and clear the dirty data marker for that month; increment the version number of June by 1 and clear the dirty data marker for that month. ④ All dirty markers are cleared to zero, reconstruction complete. Key advantages: Dirty marking is an explicit state: the presence of a dirty mark indicates a need for rebuilding, while the absence of a dirty mark indicates data consistency. Version numbers serve only as a historical record of the number of rebuilds per month and are not involved in any crash recovery logic. After a system restart, only the `is_dirty` field of a single table needs to be scanned to locate all breakpoints, without relying on logs, version number comparisons, or cascading range records. Newly generated normal month-end months have `is_dirty` = false and will never be mistakenly considered to require rebuilding.

[0023] Example 7: Account Set-Level Concurrency Locking Deleting the February voucher triggers cascading task A. Task A acquires an exclusive lock on the accounting set, marks the carry-over vouchers from February to June as dirty data, and performs reconstruction layer by layer. During the reconstruction, all business voucher add, delete, and modify operations in the accounting set are blocked and wait. After Task A completes the reconstruction (clearing all dirty data markings from February to June), it releases the lock, and subsequent operations proceed normally.

[0024] Example 8: Automatic Integration of Batch Import of Historical Vouchers Real-world scenario: A company started using this accounting system in June 2025. Previously, the accounts for January to May were maintained in Excel. The accountant exported all vouchers from January to May as a comma-separated value file (CSV) and imported them into the system in batches. A total of 300 vouchers from 5 months were imported. Operation process: 1. Accountants should select the "Batch Import" function and upload a CSV file containing vouchers from January to May. 2. The system parses the CSV file and distributes the 300 vouchers by date to each month: January (60 vouchers), February (55 vouchers), March (70 vouchers), April (50 vouchers), and May (65 vouchers). 3. Complete writing to the business voucher table. The system processes this automatically (no manual intervention required): Step 1: After the import is complete, the voucher change detection module captures INSERT events in the business voucher tables for all five months from January to May. Step 2: Determine the earliest change month M=2025-01, and the current month C=2025-06 (vouchers may already exist in June). Mark all entries [01, 02, 03, 04, 05, 06] as dirty data, i.e., set the dirty data flag field is_dirty to true. Step 3: Cascade Reconstruction Scheduling Start: Reconstruct January: The beginning balance of the first month is zero. Based on the 60 vouchers in January, generate January carryover voucher v1 and clear the dirty data markers for that month. Reconstruct February: Read the January carryover vouchers, combine them with the 55 February vouchers to generate February carryover voucher v1, and clear the dirty data markers for that month. Reconstruct March: Read the February carryover vouchers, combine them with the 70 March vouchers to generate March carryover voucher v1, and clear the dirty data markers for that month. Reconstruct April: Read the March carryover vouchers, combine them with the 50 April vouchers to generate April carryover voucher v1, and clear the dirty data markers for that month. Reconstruct May: Read the April carryover vouchers, combine them with the 65 May vouchers to generate May carryover voucher v1, and clear the dirty data markers for that month. Reconstruct June: Read the May carry-over vouchers, combine them with the June vouchers (if any), calculate and generate the June carry-over voucher v1, and clear the dirty data markers for that month. Step 4: Write to the audit log: "Batch import of 300 vouchers from January 2025 to May 2025, triggering 6-level cascading reconstruction complete" User experience: After importing the CSV, open the ledger for any month—the balances are all correct, eliminating the need to manually "reclose the accounts" month by month; it's ready to use immediately after import.

[0025] Example 9: Automatic Completion of Gaps in Monthly Accounting Real-world scenario: A self-employed individual uses this system for bookkeeping. Bookkeeping was conducted normally from January to March 2025, but was suspended in April due to personal matters. Bookkeeping resumes in September 2025—starting with entering business vouchers on September 1st. Current status: January: There are vouchers and carryover v1 (bank deposit ending balance is 200,000 yuan). February: There are vouchers and carryover v1 (bank deposit ending balance is 350,000 yuan). March: There are vouchers and carryover v1 (bank deposit ending balance is 500,000 yuan). April: No vouchers, no carry-forward. May: No vouchers, no carry-forward June: No vouchers, no carry-forward July: No vouchers, no carry-forward. August: No vouchers, no carry-forward. September: Voucher available (just entered) The system automatically triggers after the user enters the September voucher: The first step, gap detection: The system attempts to retrieve the opening balance for September, searches for the carry-over vouchers for August, finds none, and traces back to March where carry-over vouchers exist, thus identifying the gap window as April to August. The second step is to automatically generate bridging carry-over vouchers: Bridging to April: Read the March closing voucher (bank deposit of 500,000), April has no voucher transactions and the amount is zero, the April closing balance is 500,000, and generate a bridging closing voucher. Bridged May: Read the bridging carry-forward voucher from April (bank deposit of 500,000), there are no vouchers in May and the transaction amount is zero, the ending balance in May is 500,000, and a bridging carry-forward voucher is generated. Bridged June: Read the bridging carry-forward voucher from May (bank deposit 500,000), there are no vouchers in June and the amount is zero, the ending balance in June is 500,000, generate the bridging carry-forward voucher. Bridged July: Following the same logic, the closing balance for July is 500,000, generating a bridging carry-forward voucher. Bridging to August: Following the same logic, the closing balance for August is 500,000, generating a bridging carry-forward voucher. Step 3, Normal Month-End Closing in September: Read the August bridging carry-over voucher (bank deposit 500,000) to obtain the beginning balance, iterate through the September business vouchers (assuming bank deposit increases by 100,000), the ending balance in September is 600,000, and generate a normal month-end closing voucher (version v1). The fourth step is to write the following to the log: "Automatically fill the gap: April to August 2025 (5-month gap), generate 5 bridging carry-over vouchers, and restore data chain continuity." User experience: Users only need to start entering vouchers in September, and the system will automatically bridge the gaps from April to August. Users do not need to manually enter zero-amount vouchers for the gap months, nor do they need to perform any "empty closing" operations. The longer the gap, the more prominent the value of this invention becomes—even with a gap of 24 months (2 years), the system will automatically generate all bridging carry-forward vouchers within seconds.

[0026] Bridging transfer vouchers vs. normal month-end closing vouchers Normal monthly closing voucher: Generation trigger is automatic at the end of the month, the type is marked as "normal monthly closing", the number of business vouchers in the current month is not less than zero, the ending balance is the beginning balance plus the changed debit / credit difference, and it participates in cascading reconstruction; Bridged carryover vouchers: generated automatically when the gap detection is triggered, the type is marked as "automatic bridging", the number of business vouchers in the current month is strictly 0, the ending balance is always equal to the beginning balance (the balance is passed on as is), and it also participates in cascading reconstruction.

[0027] Key data structures In this invention, the carry-forward voucher record in the carry-forward voucher storage unit includes the following fields: primary key identifier, account set identifier, month, version number (recording the cumulative number of times the carry-forward voucher for that month has been rebuilt), dirty data marker (indicating that the carry-forward voucher for that month needs to be rebuilt), voucher type marker (including three types: normal month-end closing, automatic bridging, and cascading reconstruction), account balance data, creation time, and update time; wherein, only one carry-forward voucher record is allowed to exist in the same month of the same account set; The log records in the cascading reconstruction log table include the following fields: primary key identifier, account set identifier, trigger type (including voucher change, batch import, and gap filling), trigger event description, start month, end month, reconstruction level, difference summary, operator and creation time.

[0028] Industrial applicability This invention has been implemented and applied in accounting software systems in this field, and is suitable for individual businesses and small and medium-sized enterprises. It has been practically verified, especially in the following scenarios: - Batch import scenario: When enterprises switch accounting software, they can import historical monthly vouchers at once, and the import will be automatically linked after batch import; - Scenario of missing accounting entries: If a self-employed individual or micro-enterprise resumes accounting after not keeping records for several consecutive months, the system will automatically fill the gaps. The embodiments of the present invention are clear and complete, and can be implemented by those skilled in the art based on the specification and examples, thus possessing industrial applicability.

Claims

1. A method for calculating incremental accounting data based on monthly carry-over snapshots, characterized in that, Includes the following steps: Step S1, Month-end carry-over snapshot generation: At the end of each month, automatically traverse all business vouchers for the month, summarize the cumulative debit and credit amounts by accounting subject, calculate the ending balance of each subject, summarize the ending balance of each subject into a carry-over voucher record, and persistently store the carry-over voucher in the carry-over voucher storage unit. Step S2, Obtaining the Initial Balance: When it is necessary to query the account balance for month N, the carry-over voucher for month N-1 is read from the carry-over voucher storage unit, and the ending balance data of all accounts in it is extracted as the initial balance for month N. If there is no carry-over voucher for month N-1, the process is traced back to the most recent month L with a carry-over voucher, where L is less than N minus 1. The ending balance of month L is used as the basis for the initial balance, and carry-over vouchers are generated sequentially for each gap month between month L plus 1 and N minus 1. The ending balance of each account in the carry-over voucher for each gap month is exactly equal to the ending balance of the corresponding account in the carry-over voucher of the previous month. Since there are no business vouchers in the gap month, the initial balance is passed on unchanged to the end of the period. When N is the first month of the account set, the initial balance is zero. If the month L does not exist, the initial balance is zero. Step S3, Incremental Balance Calculation: Traverse all business vouchers in the Nth month, and calculate the debit and credit amounts of each account in the current month; combine the beginning balance obtained in step S2 with the calculated amount for the current month to calculate the ending balance of each account in the Nth month. Step S4, Change Detection and Marking: When an add, delete, or modify operation is detected on a business voucher in month M, all subsequent months from month M to the current accounting period are marked as pending reconstruction. Step S5, Cascaded Reconstruction: For each month in the state to be reconstructed, the reconstruction operation is performed month by month in ascending order. Each layer of reconstruction includes: reading the carry-over vouchers of the previous month to obtain the beginning balance, traversing all business vouchers of the current month to calculate the transaction amount, generating new carry-over vouchers and overwriting the old carry-over vouchers of the same month; when the ending balance after a certain layer of reconstruction is the same as before reconstruction, the subsequent months of that layer will not continue to be cascaded.

2. An accounting data incremental calculation system based on monthly carry-over snapshots, characterized in that, include: The carry-forward voucher generation module is used to automatically traverse all business vouchers of the month at the end of each month, summarize the cumulative debit and credit amounts of each accounting subject, generate carry-forward vouchers containing snapshot data of the end-of-period balances of each subject for the month, and persistently store them in the carry-forward voucher storage unit. The balance query interface module is used to receive query requests for the target month N, read the carry-over vouchers of month N-1 from the carry-over voucher storage unit to obtain the beginning balance, traverse the business vouchers of month N to calculate the monthly transaction amount, and combine the beginning balance and transaction amount to calculate the ending balance of each account and return it. The voucher change detection module is used to capture the addition, deletion, and modification events of business vouchers, determine the starting month M of the change, and write all subsequent months from M to the current accounting period into the queue of months to be rebuilt. The cascading reconstruction scheduling module is used to mark all carry-over vouchers in the affected month set as dirty data. Then, starting from the earliest dirty data month, it performs reconstruction month by month in ascending order. It reads the carry-over vouchers of the previous month to obtain the opening balance, iterates through the business vouchers of the current month to calculate the transaction amount, generates new carry-over vouchers to overwrite the old carry-over vouchers, increments their version number by 1 and clears the dirty mark. If the ending balance of a certain month is the same as before the reconstruction, the current cascading reconstruction of this set of accounts is terminated. The cascading log recording module is used to record the triggering reason, affected month range, operation time, and operator information for each cascading rebuild operation.

3. The method as described in claim 1, characterized in that, The carry-over voucher includes a voucher type marker, a month field, and a list of account balances. Each account balance record includes an account code, account name, cumulative debit amount, cumulative credit amount, end-of-period balance direction identifier, and end-of-period balance amount.

4. The method as described in claim 1, characterized in that, Before the cascading reconstruction begins, all carry-over vouchers in the affected month set are marked as dirty data, i.e., the dirty data flag field `is_dirty` is set to true. The dirty data state is the specific implementation of the "to be rebuilt state" in claim 1 at the database level. During the layer-by-layer reconstruction process, after each month's reconstruction is completed, the version number of the carry-over voucher for that month is incremented by 1 and its dirty flag is cleared, i.e., the `is_dirty` field value of the carry-over voucher for that month is set to false. The version number is only used to record the cumulative number of times the carry-over voucher for that month has been rebuilt and is not used as a basis for determining whether the reconstruction is complete. If a system interruption occurs, after restarting, the carry-over voucher storage unit is scanned to check if there are any dirty data records with the dirty data flag field `is_dirty` set to true. If so, the earliest dirty data month is found, and reconstruction is re-executed for all dirty data months in ascending order of time starting from that month.

5. The method as described in claim 1, characterized in that, The cascaded reconstruction link automatically crosses the natural year boundary without needing to distinguish between years.

6. The method as described in claim 1, characterized in that, Cascading rebuilds are executed at the account set level, and only one cascading task is allowed to run at any given time within the same account set.

7. The method as described in claim 1, characterized in that, Configure a database trigger in the business voucher table to automatically generate a change event when INSERT, UPDATE, or DELETE operations are detected.

8. The method as described in claim 1, characterized in that, After each layer is rebuilt, the balance change is written to the cascading rebuild log table, which includes a description of the triggering event, the affected month, the balance snapshot, and the operation timestamp.

9. The method as described in claim 1, characterized in that, The balance query operations in steps S2 and S3 only access one carry-over voucher record from month N-1 and the current month's business voucher record from month N. The number of database records involved in the query is the number of vouchers in month N plus one, and is not affected by the total number of business vouchers accumulated since the account set was put into use.

10. The method as described in claim 1, characterized in that, After each layer is rebuilt, the snapshot of the ending balance before and after the monthly reconstruction is compared. If the ending balance of all accounts has not changed, the cascading reconstruction of subsequent months is automatically terminated, and all dirty data in the affected months that have not yet been rebuilt are cleared. The affected months that have not yet been rebuilt include the months after the current month that have been marked as dirty data, while keeping the existing balance data of these months unchanged.

11. The method as described in claim 1, characterized in that, When multiple business vouchers are imported into the Mth month in a batch, the system treats the entire batch import operation as a single change event and determines the affected month range as from the earliest month in which the data change occurred to the current accounting period. Step S4 marks all months in the affected month range as to be rebuilt at once. Step S5 performs a cascading reconstruction layer by layer from the earliest affected month, traversing all subsequent months, instead of triggering a cascading reconstruction for each imported voucher separately.

12. The method as described in claim 1, characterized in that, Before generating the carry-over voucher for month N, check if there is a carry-over voucher for month N-1. If there is no carry-over voucher for month N-1, trace back to the most recent month L with a carry-over voucher, where L is less than N minus 1, and perform a gap filling step: For each gap month from month L+1 to N-1, generate carry-over vouchers sequentially. The ending balance of each account in the carry-over voucher for each gap month is exactly equal to the ending balance of the corresponding account in the carry-over voucher of the previous month. Since there are no business vouchers in the gap month, the beginning balance is passed on unchanged to the end of the period. The carry-over vouchers generated in the gap month are marked as automatic bridging type, which distinguishes them from the carry-over vouchers generated by normal month closing and the carry-over vouchers generated by cascading reconstruction. After filling the gap, generate the carry-over voucher for month N.

13. The system as described in claim 2, characterized in that, Before the cascading reconstruction starts, the cascading reconstruction scheduling module marks all carry-over vouchers in the affected month set as dirty data, that is, sets the dirty data marking field is_dirty to true; during the layer-by-layer reconstruction process, after each month is reconstructed, the version number of the carry-over voucher for that month is incremented by 1 and its dirty marking is cleared. If a system interruption occurs, after restarting, scan the carry-over voucher storage unit to check if there are any dirty data records where the dirty data flag field is_dirty has a true value. If so, find the earliest dirty data month and re-execute the reconstruction in ascending order of time starting from that month.

14. The system as described in claim 2, characterized in that, The cascading reconstruction scheduling module locks the account set level to execute cascading reconstruction. Only one cascading task is allowed to run in the same account set at any given time. After each layer of reconstruction, the snapshot of the period-end balance before and after the reconstruction of that month is compared. If the period-end balance of all accounts has not changed, the cascading reconstruction of subsequent months is automatically terminated, and all dirty data in the affected months that have not yet been reconstructed is marked and cleared, while keeping the existing balance data of these months unchanged.

15. The system as described in claim 2, characterized in that, It also includes a gap filling module, which is used to check whether there is a carry-over voucher in month N-1 before generating the carry-over voucher for month N. If it does not exist, it traces back to the most recent month L with a carry-over voucher (L is less than N minus 1), and generates carry-over vouchers sequentially for each gap month between month L plus 1 and N minus 1. The ending balance of each account in the carry-over voucher of each gap month is exactly equal to the ending balance of the corresponding account in the carry-over voucher of the previous month.

Images