Intelligent Financial Document Parser & Reconciliation System
Budget: ₹12,500 – ₹37,500 INR
I am seeking a developer to build an updated and more intelligent version of my current financial reconciliation system. At present, I have a working Python script that performs basic reconciliation between two ledgers contained within a single Excel workbook. This script reads data from two predefined sheets, assuming a fixed layout with headers in row 4 and transactional data beginning from row 5. It matches transactions using hardcoded rules for exact matches, fuzzy matches based on date tolerance, split matches for amounts split across entries, and rounding matches within a fixed threshold. The output is a formatted Excel file with color-coded rows and remarks for matched and unmatched entries.
While this current system functions reliably under specific conditions, it is limited in flexibility and scope. It only works with .xlsx files, requires a fixed format, and does not account for files with missing ledger names, varied column headers, or unstructured inputs. It also does not support scanned documents or multiple files from the same or different ledgers.
This project is intended as a direct update to that system. The goal is to build a more intelligent, robust, and scalable solution that can process documents in a variety of formats including Excel files, scanned PDFs, and image formats such as JPEG or PNG. The updated system should use OCR to extract data from scanned files and images, and incorporate machine learning or rule-based logic to identify whether the file contains financial transactional data, detect column headers even when inconsistently named, and classify or infer the type of ledger.
The system must be able to handle real-world complexities such as:
• Multiple files from the same ledger,
• Missing or inconsistent ledger or company names,
• Differently named headers (e.g., “Dr Amt” instead of “Debit”),
• Poorly scanned or partially structured files.
Before performing reconciliation, the user should be able to review a preview of the data, validate column mappings, and confirm the presence of opening and closing balances where applicable. The system should also allow the user to view any inconsistencies or mismatches identified during data extraction—such as incorrect dates, unrecognized columns, or missing values—and manually edit or approve these before proceeding with reconciliation. This will ensure greater accuracy and flexibility, especially when working with scanned documents or files from different sources.
The reconciliation logic from the current system should be retained, but restructured to allow user customization. The user should be able to configure parameters such as:
• Tolerance for exact match (e.g., amount ± ₹0.01),
• Fuzzy match date range (e.g., ± 7 days),
• Split match logic (e.g., one transaction vs. multiple entries),
• Rounding difference allowance (e.g., up to ₹0.50),
• Enabling or disabling certain match types.
This configuration should be manageable either through a settings file (e.g., JSON or YAML) or a minimal interface. The output should remain an Excel workbook with color-coded rows, a remarks column, a summary of reconciliation status, and optionally an error log or audit trail.
The updated solution should be modular, extensible, and easy to use. While a graphical interface is optional, a simple user interface for uploading files, reviewing settings, and triggering reconciliation would improve usability. The code should be cleanly written and documented, allowing for future features such as cloud integration, email-based ingestion, or API connectivity.
In summary, this is not a new tool from scratch but a structured upgrade to the current working reconciliation script. The objective is to expand its capabilities to handle unstructured data, multiple formats, and real-world inconsistencies while keeping the reconciliation engine familiar, customizable, and output-driven.
Let me know if you have worked on something similar in the past, particularly involving OCR, financial data processing, or reconciliation systems. If selected, I will share my existing Python script so you can understand the current structure and build upon it.
While this current system functions reliably under specific conditions, it is limited in flexibility and scope. It only works with .xlsx files, requires a fixed format, and does not account for files with missing ledger names, varied column headers, or unstructured inputs. It also does not support scanned documents or multiple files from the same or different ledgers.
This project is intended as a direct update to that system. The goal is to build a more intelligent, robust, and scalable solution that can process documents in a variety of formats including Excel files, scanned PDFs, and image formats such as JPEG or PNG. The updated system should use OCR to extract data from scanned files and images, and incorporate machine learning or rule-based logic to identify whether the file contains financial transactional data, detect column headers even when inconsistently named, and classify or infer the type of ledger.
The system must be able to handle real-world complexities such as:
• Multiple files from the same ledger,
• Missing or inconsistent ledger or company names,
• Differently named headers (e.g., “Dr Amt” instead of “Debit”),
• Poorly scanned or partially structured files.
Before performing reconciliation, the user should be able to review a preview of the data, validate column mappings, and confirm the presence of opening and closing balances where applicable. The system should also allow the user to view any inconsistencies or mismatches identified during data extraction—such as incorrect dates, unrecognized columns, or missing values—and manually edit or approve these before proceeding with reconciliation. This will ensure greater accuracy and flexibility, especially when working with scanned documents or files from different sources.
The reconciliation logic from the current system should be retained, but restructured to allow user customization. The user should be able to configure parameters such as:
• Tolerance for exact match (e.g., amount ± ₹0.01),
• Fuzzy match date range (e.g., ± 7 days),
• Split match logic (e.g., one transaction vs. multiple entries),
• Rounding difference allowance (e.g., up to ₹0.50),
• Enabling or disabling certain match types.
This configuration should be manageable either through a settings file (e.g., JSON or YAML) or a minimal interface. The output should remain an Excel workbook with color-coded rows, a remarks column, a summary of reconciliation status, and optionally an error log or audit trail.
The updated solution should be modular, extensible, and easy to use. While a graphical interface is optional, a simple user interface for uploading files, reviewing settings, and triggering reconciliation would improve usability. The code should be cleanly written and documented, allowing for future features such as cloud integration, email-based ingestion, or API connectivity.
In summary, this is not a new tool from scratch but a structured upgrade to the current working reconciliation script. The objective is to expand its capabilities to handle unstructured data, multiple formats, and real-world inconsistencies while keeping the reconciliation engine familiar, customizable, and output-driven.
Let me know if you have worked on something similar in the past, particularly involving OCR, financial data processing, or reconciliation systems. If selected, I will share my existing Python script so you can understand the current structure and build upon it.