Integrated donation management system for automatic donation receipt issuance

Abstract

The present invention relates to an integrated donation management system for the automatic issuance of donation receipts. The problem to be solved is to automatically link donation input data and payment transaction data to accurately verify the same donation activity, reliably manage donation data in an integrated manner across multiple institutions, automatically generate donation receipt data based on donation history, and use this to automatically generate donation receipt documents or data files for the batch issuance of electronic donation receipts, thereby improving the convenience of donors in securing proof and the efficiency of data processing. For example, an integrated donation management system that supports automatic tax credit is disclosed, comprising: an input data receiving unit that receives donation input data regarding donor identification and donation intent from a donor; a payment data collecting unit that collects payment transaction data generated through a payment method from an external payment system; a donation activity analysis unit that generates donation activity information by performing correlation analysis between the donation input data received from the input data receiving unit and the payment transaction data collected from the payment data collecting unit; a donation history management unit that generates donation history information based on the donation activity information generated by the donation activity analysis unit, stores and manages the generated donation history information in an integrated manner, and generates donation receipt data corresponding to the donation activity information; and a receipt issuance unit that automatically generates a donation receipt document or generates a data file for batch issuance of electronic donation receipts based on the donation receipt data generated by the donation history management unit.

Description

Technology Field

[0001] Embodiments of the present invention relate to the field of donation data processing and automatic issuance of donation receipts. More specifically, the invention relates to an integrated donation management system that manages donation activity information occurring in non-profit organizations by linking it retrospectively based on donor input data and payment transaction data, generates donation receipt data corresponding to donation details, and automatically generates donation receipt documents or data files for batch issuance of electronic donation receipts based on this data. Background Technology

[0002] Recently, with the advancement of online and mobile payment technologies, individual donation activities have expanded across various channels, ranging from offline donation boxes, kiosks, and QR-based on-site donations to mobile apps, web payments, simplified payment services, and subscription-based donations. Since data for these donation activities is generated independently across disparate infrastructures—such as payment gateway (PG) systems, financial institutions, simplified payment platforms, and internal databases of non-profit organizations—and because data structures, recording times, storage formats, and identification standards differ, it is common for data units to be managed separately, even for the same donation activity.

[0003] From the donor's perspective, in order to process tax deductions or obtain proof of donation, they must individually collect and store donation receipts issued by each charity or manually enter donation details into a computerized system. This process frequently encounters issues such as lost receipts, omitted entries, errors, and missed submission deadlines, presenting a limitation in that it hinders the smooth securing of proof for donation records.

[0004] From the perspective of non-profit organizations, if donor input information and payment transaction data are not linked, or if data disconnection occurs due to network failures at the time of collection, failure to enter identification information, or missing approval numbers, the verification process for issuing donation receipts is delayed. Furthermore, errors are detected, rejections occur, and requests for reprocessing arise during the data generation stage for the batch issuance of electronic donation receipts, leading to increased administrative burden and operational costs.

[0005] Furthermore, conventional donation management systems lack algorithm-based automatic processing capabilities to match donation input data with payment transactions. As a result, they rely restrictively on the matching of approval numbers and fail to fully utilize additional data elements such as terminal information, payment location, and payment patterns, leading to frequent omissions or false positives in situations of data inconsistency.

[0006] Furthermore, the use of separate database environments for each non-profit organization makes it difficult to maintain data consistency as the number of organizations and donors increases. Additionally, the level of automation is low, as the conversion of data files for donation receipt issuance and the alignment of submission formats largely rely on manual work or external tools. Another limitation is the lack of tracking for failed matches and learning-based policy improvement functions, which prevents fundamental quality improvement even when repetitive errors occur. In particular, data that is not immediately matched at the point of donation remains in the system as an "unconfirmed donation" status, even though the actual donation has been made. This necessitates manual verification by the donor, which can result in missing donation records and delays in receipt issuance.

[0007] Furthermore, despite the expansion of electronic donation receipt systems and computerized verification frameworks at the national and public institution levels, donor convenience and administrative efficiency are not being fully ensured due to a lack of data linkage technology; consequently, there is a growing demand for new technologies for the integrated management of donation information and the automatic issuance of donation receipts.

[0008] As such, in an environment where the generation structure of donation data is diversifying and the demand for electronic receipt issuance is becoming more sophisticated, an intelligent integrated donation management system is required that can automatically align and analyze donation input data and payment transaction data, convert the data into a format suitable for issuing donation receipts, and continuously improve data quality based on the processing results. Prior art literature

[0009] Registered Patent Publication No. 10-1855312 (Registration Date: May 9, 2018) Registered Patent Publication No. 10-1207506 (Registration Date: December 3, 2012) Registered Patent Publication No. 10-0760022 (Registration Date: September 18, 2007) Registered Patent Publication No. 10-1254279 (Registration Date: April 12, 2013) The problem to be solved

[0010] An embodiment of the present invention provides an integrated donation management system for automatic issuance of donation receipts that automatically analyzes and links donation input data and payment transaction data to consistently verify donor identification information, payment approval information, and whether a donation act has actually occurred, and can accurately identify identical donation acts based thereon.

[0011] In addition, we provide an integrated donation management system for automatic donation receipt issuance that stores data generated asynchronously in heterogeneous environments—such as offline sites, online platforms, and simple payment applications—during the donation process in a multi-tenant-based integrated database, and offers data structure standardization and an access control system. This provides a donation data management environment that enables donors and organizations to query, verify, and correct highly reliable donation records in real time when necessary.

[0012] In addition, it provides an integrated donation management system for automatic donation receipt issuance that enables the automation of receipt issuance administrative procedures and the generation of error-free data by automatically generating donation receipt documents or data files for the bulk issuance of electronic donation receipts based on generated donation receipt data, converting and transmitting data while automatically reflecting standard format specifications required by tax agencies or external administrative linkage systems, and immediately feeding back error reasons and verification failure items received as processing results into donation history management.

[0013] In addition, by automatically updating matching policies based on log records and cause data for matching failures, and tracking types of recurring errors to continuously apply data quality improvement algorithms, we provide an integrated donation management system for automatic issuance of donation receipts equipped with an intelligent operating system for donation data management and self-improvement capabilities. means of solving the problem

[0014] An integrated donation management system for automatic issuance of donation receipts according to an embodiment of the present invention comprises: an input data receiving unit that receives donation input data regarding donor identification and donation intent from a donor; a payment data collecting unit that collects payment transaction data generated through a payment means from an external payment system; a donation activity analysis unit that generates donation activity information by performing correlation analysis between the donation input data received from the input data receiving unit and the payment transaction data collected from the payment data collecting unit; a donation history management unit that generates donation history information based on the donation activity information generated by the donation activity analysis unit, stores and manages the generated donation history information in an integrated manner, and generates donation receipt data corresponding to the donation activity information; and a receipt issuance unit that automatically generates a donation receipt document or generates a data file for batch issuance of electronic donation receipts based on the donation receipt data generated by the donation history management unit.

[0015] Additionally, the input data receiving unit may include: an input interface providing unit that receives donation input data from a donor by providing at least one of a fixed QR code, a dynamic QR code, a shortened URL, a kiosk UI, a mobile / web UI, and a voice-based input UI to the donor; a donor identification data generating unit that generates donor identification data to identify a donor based on at least one of unique identification information capable of distinguishing transactions included in the donation input data, a donor unique identifier, and an institution-specific member identifier; and an identity authentication processing unit that generates identity authentication result data by performing at least one of mobile phone authentication, electronic signature, and biometric authentication, stores the generated identity authentication result data by mapping it to the donor identification data, and provides the identity authentication result data as reference verification data to be referenced when analyzing the correspondence relationship between the donation input data and the payment transaction data.

[0016] In addition, the input interface providing unit receives donation input data from a donor by providing a fixed QR code attached to a guide structure or output medium placed at the donation site to the donor, provides a unique identification information input UI upon scanning the fixed QR code, and can generate auxiliary verification data that is referenced when analyzing the correspondence relationship between donation input data and payment transaction data by linking the unique identification information entered through the unique identification information input UI with donor identification data and payment transaction data.

[0017] Additionally, the payment data collection unit may include: a payment data linkage receiving unit that receives payment transaction data by linking data with at least one of a PG system, a financial institution system, and a simple payment system, in at least one of an API-based real-time method or a file upload-based post-method; a payment data verification unit that generates verification result data for payment transaction data by selecting at least one of unique identification information capable of distinguishing transactions, payment date and time, and payment amount as a verification criterion for the payment transaction data received through the payment data linkage receiving unit, and performing at least one of time verification, amount verification, and terminal identification information-based verification according to the selected verification criterion; and a payment data exception handling unit that transmits a re-collection request signal for payment transaction data to the payment data linkage receiving unit or generates administrator verification request information when inaccurate data is detected in the verification result data of the payment data verification unit.

[0018] Additionally, the donation activity analysis unit may include: an automatic matching analysis unit that generates matching result data by analyzing a correspondence relationship among at least one of unique identification information, payment date and time, payment amount, and terminal identification information capable of distinguishing transactions between donation input data received from the input data receiving unit and payment transaction data collected from the payment data collection unit; a matching determination unit that provides a matching retry request or manual matching request interface based on the matching result data generated by the automatic matching analysis unit; and a data transmission unit that transmits the matching result data generated by the automatic matching analysis unit to the donation history management unit.

[0019] In addition, the donation activity analysis unit may further include a matching key determination unit that sets the institution-specific member identifier information included in the donation input data as a key matching key applied to the analysis of the correspondence relationship between the donation input data and the payment transaction data.

[0020] In addition, the automatic matching analysis unit can extract at least one of the payment occurrence location information, payment terminal type information, and payment pattern information included in the payment transaction data as a feature quantity, compare and analyze the extracted feature quantities to determine whether there is a match between the donation input data and the payment transaction data, and generate donation activity information including the determination result.

[0021] Additionally, the donation history management unit may include: a donation history generation unit that generates donation history information by classifying donation activity information generated by the donation activity analysis unit by donor, donation institution, and donation item; a multi-tenant management unit that provides multi-tenant-based software services to enable multiple non-profit organizations to manage the donation history information generated by the donation history generation unit in the same platform environment; a donation history portal provision unit that enables viewing or requesting correction of donation history information managed by the multi-tenant management unit through a donor or administrator terminal; and a matching exception management unit that separately manages information marked as a matching failure item among the donation activity information generated by the donation activity analysis unit and transmits information regarding confirmation or correction requests for the item to the donation history portal provision unit.

[0022] In addition, the donation history management unit may further include a matching policy update unit that logs the matching status change information stored in the matching exception management unit and automatically updates the matching reliability calculation criteria and exception handling rules based on the recorded log information.

[0023] Additionally, the donation history management unit may further include a correction result reflection unit that acquires correction result data entered by a donor or manager through the donation history portal provision unit and reflects it in the matching reliability calculation criteria and exception handling rules updated by the matching policy update unit to update the matching status or stored information of the donation history information.

[0024] Additionally, the receipt issuing unit may include a format conversion processing unit that converts donation history information or donation receipt data generated by the donation history management unit into a standard format for submission to a tax agency; and a submission result transmission unit that transmits the data converted by the format conversion processing unit to a tax agency and transmits at least one of success status information, error verification information, and resubmission request information received from the tax agency to the donation history management unit. Effects of the invention

[0025] According to the present invention, by automatically performing correlation analysis between donor input data and payment transactions, precise matching based on approval numbers, payment dates and times, amounts, and payment terminal information is possible, thereby improving the accuracy of identifying donation activities and minimizing the occurrence rate of omissions and false positives.

[0026] In addition, by integrating and managing donation data generated separately by each non-profit organization into a single platform using a unified data type and relational structure, management efficiency is improved, and inconsistencies occurring during data transfer between systems can be significantly reduced.

[0027] In addition, since tax deductions can be submitted automatically without the burden of donors uploading separate supporting documents or manual input, user convenience is maximized, and it can contribute to increasing donation participation rates and spreading a culture of social giving.

[0028] In addition, continuous improvement of data consistency and accuracy is possible based on submission result data received from tax authorities, and automatic detection and correction of error data can be performed without the need for additional personnel, thereby drastically reducing operating costs and administrative processing time.

[0029] Furthermore, based on technological scalability encompassing various offline and online donation channels, it facilitates the digital transformation of the donation ecosystem and contributes to the revitalization of public-interest donation activities and the establishment of a foundation of social trust by securing data-driven transparency and efficiency in the public and non-profit sectors. Brief explanation of the drawing

[0030] FIG. 1 is a schematic diagram showing an example of the overall hardware implementation and operation process of an integrated donation management system for automatic issuance of donation receipts according to an embodiment of the present invention. FIG. 2 is a block diagram showing the overall configuration of an integrated donation management system for automatic issuance of donation receipts according to an embodiment of the present invention. FIG. 3 is a block diagram showing the detailed configuration of an input data receiving unit according to an embodiment of the present invention. FIG. 4 is a block diagram showing the detailed configuration of a payment data collection unit according to an embodiment of the present invention. FIG. 5 is a block diagram showing the detailed configuration of a donation activity analysis unit according to an embodiment of the present invention. FIG. 6 is a block diagram showing the detailed configuration of a donation history management unit according to an embodiment of the present invention. FIG. 7 is a block diagram showing the detailed configuration of a tax credit support unit according to an embodiment of the present invention. Specific details for implementing the invention

[0031] The terms used in this specification will be briefly explained, and the invention will be described in detail.

[0032] The terms used in this invention have been selected based on currently widely used general terms, taking into account their functions within the invention; however, these terms may vary depending on the intent of those skilled in the art, case law, the emergence of new technologies, etc. Additionally, in specific cases, terms have been arbitrarily selected by the applicant, and in such cases, their meanings will be described in detail in the relevant description of the invention. Therefore, the terms used in this invention should be defined not merely by their names, but based on their meanings and the overall content of the invention.

[0033] When a part of a specification is described as "comprising" a certain component, this means that, unless specifically stated otherwise, it does not exclude other components but may include additional components. Furthermore, terms such as "...part" or "module" as used in the specification refer to a unit that processes at least one function or operation, and this may be implemented in hardware or software, or as a combination of hardware and software.

[0034] Embodiments of the present invention are described below with reference to the attached drawings so that those skilled in the art can easily implement them. However, the present invention may be embodied in various different forms and is not limited to the embodiments described herein. Furthermore, in order to clearly explain the present invention in the drawings, parts unrelated to the explanation have been omitted, and similar parts throughout the specification are denoted by similar reference numerals.

[0035] FIG. 1 is a schematic diagram showing an example of the overall hardware implementation and operation process of an integrated donation management system for automatic issuance of donation receipts according to an embodiment of the present invention.

[0036] Referring to FIG. 1, the integrated donation management system (1000) for automatic issuance of donation receipts according to the present embodiment can be implemented as an integrated donation management platform for automatically analyzing and linking input-based data generated from a donor's donation activity and payment transaction data generated from a payment system at a central server (10) to calculate accurate donation details, generating donation receipt data based on the donation details, and automatically generating donation receipt documents or data files for batch issuance of electronic donation receipts. In addition, the system (1000) can be optionally extended to perform tax credit submission processing by linking with an external administrative linkage server (50).

[0037] To this end, the integrated donation management system (1000) for automatic issuance of donation receipts according to the present embodiment may include a central server (10), a donor terminal (20), a donation site device (30), and an administrator terminal (40), and may optionally be linked with an external administrative linkage server (50).

[0038] The donor terminal (20) described above can be implemented as an input and verification interface layer through which the donor interacts with the system. The donor terminal (20) can be implemented in the form of a smartphone, tablet, PC-based web browser, mobile application, voice recognition-based device, etc., and can perform QR code scanning, access to shortened URLs, keypad input, member verification, and identity authentication procedures. The donor terminal (20) can transmit information regarding the donor's intention to donate, input information for unique identification information capable of distinguishing transactions, and identification information required for donor identification to the central server (10). Additionally, the donor terminal (20) can receive information regarding the results of the donation history inquiry or the results of the donation receipt issuance from the central server (10) and display it visually, and optionally display information regarding the results of tax deduction processing together.

[0039] The donation site device (30) described above may be configured as an information collection device to support payment activities and user identification in an actual donation environment. The donation site device (30) may be configured with a QR code output medium, an NFC-based payment terminal, a POS (Point of Sale) system, a simple payment device, a payment linkage module, a site kiosk (UI), etc. The donation site device (30) may transmit payment transaction data to a central server (10), including unique identification information capable of distinguishing transactions, payment amount, payment date and time, payment terminal information, payment location information, etc. Additionally, the donation site device (30) may provide a procedure for inputting unique identification information through a UI linked with the donor terminal (20) after the payment is executed.

[0040] The above administrator terminal (40) may be implemented as an operational interface layer for a non-profit organization or system operator to manage donation data and verify system operations. The administrator terminal (40) may be composed of a server-based web administrator page, a PC terminal, an information system for administrative agencies, a dedicated operational application, etc. The administrator terminal (40) can view matching results generated by the central server (10), matching failure items, donation history storage information, donation receipt generation and issuance status information, and optional external administrative submission status information, and can perform a request for correction of donation history or auxiliary matching verification if necessary.

[0041] The central server (10) above is a core component of the present embodiment and can be implemented as a central processing unit that performs the functions of collecting and standardizing donation input data, generating donation activity information by automatically matching it with payment transaction data, storing donation history information based on the matching results, generating donation receipt data, and generating receipt documents or data files for batch issuance through a receipt issuance unit (500). The central server (10) may be configured as a cloud server, a physical server, or a distributed processing-based system including multiple processors and storage devices, and may include a data security module, an identity authentication module, a matching analysis module, an exception detection module, a policy update engine, etc. The central server (10) can perform actual service processing logic such as comparative analysis between donation input information and payment transaction data, extraction of matching failure items, reflection of correction information, generation of donation receipt data structure and configuration of document conversion parameters, and configuration of optional external administrative submission parameters. In addition, the central server (10) can be implemented as a single server, as well as a cloud-based distributed server structure or a server structure for multiple organizations.

[0042] The external administrative linkage server (50) may be configured as an external administrative system for transmitting and receiving external submission data or tax credit linkage data generated by the central server (10). The external administrative linkage server (50) may provide the central server (10) with information on success or failure based on the processing results of the submitted data, error verification information, and resubmission request information. Linkage with the external administrative linkage server (50) may be performed optionally.

[0043] The integrated donation management system (1000) configured in this manner can transmit donation input data entered by a donor terminal (20) to a central server (10) and provide payment transaction data collected through a donation site device (30) to the central server (10). The central server (10) can generate donation activity information by performing automatic matching analysis between the donation input data and the payment transaction data. The generated donation activity information can be classified and stored by donor, donation institution, and donation item, and managed as donation history information. In addition, if a matching failure item is detected, the central server (10) can separately display the item and provide it to an administrator terminal (40), and update the matching criteria and policies by reflecting the administrator's correction information input.

[0044] Meanwhile, the central server (10) can generate donation receipt data based on confirmed donation details and automatically generate donation receipt documents or generate data files for batch issuance of electronic donation receipts through the receipt issuance unit (500). Additionally, it can support tax credit processing by optionally submitting to an external administrative linkage server (50) through the format conversion processing unit (600) and the submission result delivery unit (700). The submission result is received from the external administrative linkage server (50), and if necessary, automatic error processing or re-submission control can be performed. Through this, the central server (10) can continuously manage the data flow for the entire donation processing process and improve the quality of system operation by establishing a result-based automatic learning policy.

[0045] In addition, the donor terminal (20) can increase user convenience by receiving donation receipt issuance results, donation history inquiry information, confirmation messages, etc., provided by the central server (10) in real time. The administrator terminal (40) can maintain data accuracy and administrative efficiency at a high level by performing integrated management of donation data, setting policy-based operation standards, and verifying matching failure items.

[0046] As such, the integrated donation management system (1000) for automatic issuance of donation receipts according to the present embodiment can integrally automate the entire process of collecting, matching, verifying, storing, generating and issuing donation receipts, selectively submitting to the outside and reflecting results, and improving quality of donation data through an organic linkage flow between a central server (10), a donor terminal (20), a donation site device (30), an administrator terminal (40), and an optional external administrative linkage server (50). Furthermore, it can be implemented as a new type of digital donation management service that improves both donor convenience and public administration efficiency.

[0047] Below, the detailed configuration of the integrated donation management system for automatic donation receipt issuance will be explained in more detail with reference to the attached drawings.

[0048] FIG. 2 is a block diagram showing the overall configuration of an integrated donation management system for automatic issuance of donation receipts according to an embodiment of the present invention, FIG. 3 is a block diagram showing the detailed configuration of an input data receiving unit according to an embodiment of the present invention, FIG. 4 is a block diagram showing the detailed configuration of a payment data collection unit according to an embodiment of the present invention, FIG. 5 is a block diagram showing the detailed configuration of a donation activity analysis unit according to an embodiment of the present invention, FIG. 6 is a block diagram showing the detailed configuration of a donation history management unit according to an embodiment of the present invention, and FIG. 7 is a block diagram showing the detailed configuration of a format conversion processing unit and a submission result transmission unit for external administrative submission according to an embodiment of the present invention.

[0049] Referring to FIG. 2, the integrated donation management system (1000) for automatic issuance of donation receipts according to an embodiment of the present invention may include at least one of an input data receiving unit (100), a payment data collection unit (200), a donation activity analysis unit (300), a donation history management unit (400), and a receipt issuance unit (500).

[0050] The above input data receiving unit (100) can receive donation input data regarding donor identification and donation intent from the donor.

[0051] To this end, the input data receiving unit (100) may include at least one of an input interface providing unit (110), a donor identification data generating unit (120), and a self-authentication processing unit (130), as illustrated in FIG. 3.

[0052] The above input interface providing unit (110) can receive donation input data from a donor by providing at least one of a fixed QR code, a dynamic QR code, a shortened URL, a kiosk UI, a mobile / web UI, and a voice-based input UI to the donor.

[0053] More specifically, the input interface providing unit (110) can implement a user interface accessible in both online and offline situations to provide various input environments for a donor to express their intention to donate. The input interface providing unit (110) can support the submission of donation input data by presenting a fixed QR code, which is printed on a donation site installation and provided in a fixed manner, to the donor so that the donor can scan it using a smartphone camera. The fixed QR code can be used reliably even in environments where internet connection quality is low or system connectivity is limited, and upon scanning by the donor, a UI for inputting unique identification information that can distinguish transactions can be immediately provided from the server, thereby encouraging rapid participation in donation. For example, a fixed QR code may be included in informational materials attached at specific locations, such as outdoor donation campaigns or the entrance of welfare facilities, and when a donor scans it, the input interface providing unit (110) can dynamically load a UI for inputting unique identification information that can distinguish transactions linked to donor identification data, and utilize it as donation input data.

[0054] Additionally, the input interface providing unit (110) can provide a dynamic QR code to the donor that is generated and updated in real time in conjunction with payment terminal information or a donor authentication procedure. The dynamic QR code may include unique parameters (donation campaign ID, donation terminal ID, time information, etc.) at the time of donation, thereby ensuring the individuality of each donation act and preventing information confusion or security threats resulting from the reuse of the same QR code. For example, the dynamic QR code may be displayed on the electronic payment terminal screen, and when the donor scans it, the linkage between the donation history and the payment transaction data may be automatically performed.

[0055] Additionally, the input interface providing unit (110) can generate and provide a shortened URL that enables a text or message-based donation process. The shortened URL can be easily inserted into social media, promotional messages, campaign web pages, etc., thereby significantly improving the accessibility of donations. When accessing the shortened URL, a browser-based input UI is automatically launched, allowing the donor to proceed with the donation process immediately without installing a separate app. This configuration is suitable for large-scale influx linked to donation promotion activities and can also contribute to the generation of influx path analysis data.

[0056] Additionally, the input interface providing unit (110) can provide a kiosk UI placed at the donation site. The kiosk UI can improve accessibility for users who have difficulty making mobile-based donations, such as the elderly, people with disabilities, or non-smartphone users, and can be configured to provide a touch-based user experience so that donation information can be entered directly and assistance from an administrator can be received if necessary. For example, a donation amount selection UI, a user authentication screen transition UI, and an information input UI for external submission can be guided step-by-step.

[0057] Additionally, the input interface providing unit (110) can provide a donation input environment based on a graphical user interface through a mobile app or web UI. The mobile / web UI can be combined with features that enhance user experience, such as automatic retrieval of member information, guidance on recommended donation amounts, and visualization of donation status by institution. In this case, the UI is implemented in a responsive form to provide optimal readability and operability on various screen sizes.

[0058] Additionally, the input interface providing unit (110) can receive donation input data through voice commands based on voice recognition technology. The voice-based input UI can be effectively utilized in environments where the use of a visual interface is restricted or where a non-contact method is required. When a donor speaks the donation amount, intention to donate, and authentication information, the information can be accurately interpreted and converted into donation input data through a natural language processing algorithm. For example, a donation can be made without touch through a donor's voice command in a waiting room of a medical institution.

[0059] In this way, the input interface providing unit (110) can provide a fixed QR code, a dynamic QR code, a shortened URL, a kiosk UI, a mobile / web UI, and a voice-based input UI individually or in combination depending on the situation, thereby supporting various channels through which a donor can participate in donation without restrictions on location, device type, or access environment. Through this environment, the donor can accurately convey their intention to donate and identification information to the system with minimal procedures, and the system can ensure high accessibility and user convenience.

[0060] Meanwhile, the input interface providing unit (110) receives donation input data from the donor by providing a fixed QR code attached to a guide structure or output medium placed at the donation site to the donor, and provides a unique identification information input UI that can distinguish transactions when the fixed QR code is scanned, and can generate auxiliary verification data that is referenced when analyzing the correspondence between donation input data and payment transaction data by linking the unique identification information that can distinguish transactions entered through the unique identification information input UI that can distinguish transactions with donor identification data and payment transaction data.

[0061] More specifically, the input interface providing unit (110) can support the donor in immediately starting the donation process without installing a separate application or accessing a kiosk by visually presenting a fixed QR code attached to a guide structure, guide stand, poster, banner, or other display media placed at the donation site to the donor. The fixed QR code may include campaign information, recipient organization information, and a site identification code, and this information can be used as initial reference data for processing donation input data. For example, when a donor scans a fixed QR code attached to a hospital lobby with a smartphone, the input interface providing unit (110) can automatically execute a unique identification information input UI that can distinguish transactions in the donor's browser environment.

[0062] Additionally, the input interface providing unit (110) may provide a screen that allows the donor to directly input unique identification information that can distinguish transactions through a UI for inputting unique identification information that can distinguish transactions. The unique identification information that can distinguish transactions may be implemented as an approval number assigned by an external payment system, a transaction ID generated by the system, a token value, a hash value, or a random number-based identification value, and may be linked with the donor identification data generation unit (120) or the payment data collection unit (200) based on the unique identification information to improve the accuracy of donor identification. The unique identification information that can distinguish transactions may be composed in various formats such as numbers, characters, or mixed strings, and the UI for inputting unique identification information that can distinguish transactions may be configured in a way that enhances readability and input convenience by considering the mobile phone screen size, accessibility features, language settings, etc. For example, automatic activation of the number pad on the screen, automatic formatting function, and voice guidance function may be applied.

[0063] Additionally, the input interface providing unit (110) can generate auxiliary verification data that is referenced in the process of analyzing the correspondence between donation input data and payment transaction data by linking the unique identification information that can distinguish a transaction, entered through the unique identification information input UI that can distinguish a transaction, with donor identification data and payment transaction data. This auxiliary verification data can be utilized as a reliability enhancement factor to prevent identification errors or data conflicts when the system (1000) determines automatic or manual matching. For example, if the unique identification information that can distinguish a transaction matches a specific authentication factor included in the payment transaction data, the reliability of the match can be enhanced so that it can be processed preferentially in the subsequent verification step; if the unique identification information that can distinguish a transaction is inaccurate or fails format verification, a request for re-entry or an administrator verification procedure can be automatically triggered.

[0064] Additionally, the input interface providing unit (110) can record input time information, input terminal characteristics, location-based information, etc., that occur during the process of inputting unique identification information capable of distinguishing transactions, and such data can be used as characteristic data to detect in advance unintended data errors or the possibility of fraudulent use during the donation behavior analysis stage. For example, if the same unique identification information is repeatedly input at multiple locations at abnormally short time intervals, the system (1000) can perform suspicious pattern analysis and perform separate verification on the matching result of the unique identification information.

[0065] Accordingly, the input interface providing unit (110) can simultaneously secure the reliability and matching accuracy of the donation input data by combining immediate accessibility through a fixed QR code and an auxiliary verification mechanism through the input of unique identification information that can distinguish transactions, and can contribute to improving the overall data quality of the system (1000) and ensuring the stability of the donation process automation.

[0066] The donor identification data generation unit (120) can generate donor identification data to identify a donor based on at least one of unique identification information capable of distinguishing transactions included in the donation input data, a unique donor identifier, and an institution-specific member identifier.

[0067] More specifically, the donor identification data generation unit (120) can generate donor identification data to accurately identify the individual donor by utilizing at least one of unique identification information capable of distinguishing a transaction entered by the donor, a donor unique identifier, and an institution-specific member identifier. The unique identification information capable of distinguishing a transaction may be an approval number assigned by an external payment system, a transaction ID generated by the system, or a token value, and this can be used as an element to supplementarily verify the linkage between the donor's actual payment activity and their intention to donate. For example, when a donor scans a QR code to access an input screen and directly inputs unique identification information capable of distinguishing a transaction, the donor identification data generation unit (120) can ensure data reliability by performing verification of the format conformity of the unique identification information, checking the validity period, and comparing it with the issuing entity information.

[0068] Additionally, the donor identification data generation unit (120) can receive a unique donor identifier and use it as a core identification factor. The unique donor identifier can be generated based on personal identification information registered by the donor in advance through online membership registration, registration as a sponsor of a social welfare organization, or participation in a social contribution program of a company or institution, and may include an encrypted user ID, a hash-based unique index, or a tokenized user identification key. By utilizing such a unique identifier, the donor can automatically link past donation history and information for external submission without unnecessary re-entry of personal information at every donation, and the system (1000) can maintain a high degree of data consistency while satisfying personal information protection requirements.

[0069] In addition, the donor identification data generation unit (120) can utilize institution-specific member identifiers to link with existing donor information systems managed within specific non-profit organizations or social welfare institutions. The institution-specific member identifiers can be, for example, a unique offering number within a church or cathedral, a barcode number issued by a sponsoring organization, a unique code for a hospital volunteer, or a community sponsorship member card number. By combining with the internal system of the relevant institution, the efficiency of integrating donation history and managing long-term sponsorship relationships can be maximized. This information can also provide high accuracy during the submission and verification process, which requires a trust-based linkage with external institutions.

[0070] Additionally, the donor identification data generation unit (120) can generate donor identification data by mutually verifying multiple input identification information and assigning weights according to the matching reliability. For example, if both the unique identification information capable of distinguishing transactions and the donor unique identifier match, it can be classified as an identification result with high reliability; if only the unique identification information capable of distinguishing transactions matches or only the member identifier by institution is input, it can be configured to perform an additional verification procedure through an intermediate level of reliability judgment. To this end, the donor identification data generation unit (120) can continuously improve the identification algorithm by evaluating the actual usage environment, error input patterns, whether the same account has been stolen or duplicate registration has occurred, etc., based on machine learning.

[0071] Additionally, the donor identification data generation unit (120) may not directly store essential personal information during the identification processing process, but instead convert it into an encrypted / de-identified based token and store it in the internal database of the system (1000). This is a measure to satisfy the Personal Information Protection Act and security authentication elements, and allows for the safe and efficient utilization of data, such as the accumulation of duplicate donation history, analysis of long-term sponsorship participation, and management of submission and verification information, by reusing the same identification token during the process of the donor continuously making donations.

[0072] Accordingly, the donor identification data generation unit (120) combines three identification axes—authentication based on unique identification information capable of distinguishing transactions, securing consistency based on unique identifiers, and linkage with external systems based on member identifiers for each institution—to accurately and reliably connect the relationship between the donor's actual behavior and payment information, and to improve the overall data accuracy and verification stability of the system (1000).

[0073] The above-mentioned identity authentication processing unit (130) performs at least one of mobile phone authentication, electronic signature, and biometric authentication to generate identity authentication result data, maps the generated identity authentication result data to donor identification data and stores it, and can provide the identity authentication result data as reference verification data to be referenced when analyzing the correspondence relationship between donation input data and payment transaction data.

[0074] More specifically, the identity verification processing unit (130) can perform a multi-factor authentication procedure to additionally verify the donor's actual identity, in addition to primary identification information based on unique identification information that can distinguish the transaction entered by the donor. The identity verification processing unit (130) supports at least one of mobile phone authentication, electronic signature, and biometric authentication, thereby allowing for the application of a flexible authentication method depending on the terminal and access environment possessed by the donor. For example, if the donor enters a mobile phone number and submits a one-time authentication code based on carrier authentication or notification text, the identity verification processing unit (130) can verify the donor's identity by performing a linkage verification between the data and the identification token generated by the donor identification data generation unit (120).

[0075] Additionally, the identity verification processing unit (130) can link various electronic signature-based authentication systems, such as joint certificates, financial certificates, and local government certificates, and the electronic signature data signed by the donor can be stored in an encrypted state within the system (1000). Such electronic signature-based authentication can provide high reliability in the use of externally submitted data linked with financial institutions, public institutions, etc. For example, in the case of certain high-value donations, an additional electronic signature may be required to prevent fraudulent use or proxy donation activities.

[0076] Additionally, the identity authentication processing unit (130) can provide a contactless authentication procedure by utilizing biometric authentication such as fingerprints, faces, and irises. Since biometric authentication utilizes an individual's unique physical information, it can provide a much higher level of security compared to unique identification information and password-based authentication that can distinguish transactions. In this process, the biometric information itself is not stored, and only an irreversible authentication token generated based on feature points is stored in the system (1000), thereby complying with personal information protection standards. For example, when a donor performs fingerprint authentication through a mobile app, the identity authentication processing unit (130) can generate an authentication token by linking with the biometric authentication sensor module of the terminal and store it by linking it with donor identification data.

[0077] In addition, the identity verification processing unit (130) can legally process various subsequent data, such as managing the continuous donation history of the same donor, linking with external administrative submissions, and analyzing participation in sponsorship campaigns, by accurately mapping and storing the generated identity verification result data with the donor identification data. For example, if the same donor uses the same authentication method in different campaigns, the system (1000) can automatically identify repeated donations by the same person and continuously apply result verification without resubmitting personal information.

[0078] Additionally, the identity verification processing unit (130) can provide the identity verification result data as reference verification data during the analysis of the correspondence between the donation input data and the payment transaction data. That is, it can be utilized as a factor to increase the reliability of the matching result. If the matching based on unique identification information that can distinguish transactions is ambiguous, or if there are errors in some of the data received from the payment data collection unit (200), the final decision on whether to match can be made based on the reference verification data provided by the identity verification processing unit (130). For example, different reliability weights can be assigned according to the authentication method to prioritize the processing of biometric authentication-based matching cases over mobile phone authentication.

[0079] Accordingly, the identity verification processing unit (130) can ensure reliable verification of who the donor is, enhance the matching accuracy of donation input data and payment transaction data, satisfy both data integrity and personal information protection standards, and contribute to improving the overall security and service quality of the system (1000).

[0080] The above payment data collection unit (200) can collect payment transaction data generated through a payment method from an external payment system.

[0081] To this end, the payment data collection unit (200) may include a payment data linkage receiving unit (210), a payment data verification unit (220), and a payment data exception processing unit (230), as illustrated in FIG. 4.

[0082] The above payment data linkage receiving unit (210) can receive payment transaction data including at least one of unique identification information capable of distinguishing a transaction, payment date and time, and payment amount from an external payment system.

[0083] More specifically, the payment data linkage receiving unit (210) can receive payment transaction data in real time through a communication channel with an external payment system. The external payment system may include a card payment network, a simple payment service, a mobile payment platform, a bank debit payment system, etc., and the payment data linkage receiving unit (210) can reliably receive payment data according to a standard API or secure communication protocol provided by each system. For example, in the case of card payment, payment approval data including unique identification information that can distinguish a transaction including an approval number, a transaction time, and an approval amount can be received from a VAN company or card company server and used as basic data for the donation data matching process.

[0084] Additionally, the payment data linkage receiving unit (210) can be linked with control data from different payment occurrence points depending on the online / offline donation environment. For example, in the case of payment data generated from an on-site donation terminal, it can be transmitted immediately along with the terminal identification value, and in the case of online payment, the PG company approval response data can be immediately transmitted to the server for processing. This collection method can minimize the data gap between payment methods and reduce the time difference between the time of payment occurrence and the collection of donation data, thereby improving matching accuracy.

[0085] Additionally, the payment data linkage receiving unit (210) can receive payment transaction data using a split input method or a batch delivery method. The split input method is a method of receiving data immediately upon the occurrence of individual payments, while the batch delivery method is a method in which bundles of payment data are transmitted in bulk after a certain period of time. The payment data linkage receiving unit (210) can support both methods, and in particular, in the case of the batch delivery method, it can perform data transmission timestamp comparison and duplicate reception prevention filtering to minimize data consistency issues caused by transmission delays. Additionally, the payment data linkage receiving unit (210) can receive payment transaction data provided by an external payment system using a file upload-based post-transmission method, and the file may be provided in the format of Excel, text, or structured data file.

[0086] Additionally, the payment data linkage receiving unit (210) can interpret payment approval data in various formats, such as JSON, XML, and binary packets, considering the variability of the received data format, and convert it into an internal common format that can be processed by the donation activity analysis unit (300) or the donation history management unit (400). In this process, unique identification information that can distinguish transactions can be processed first as a core value directly used for matching, the payment date and time can be used as a reference value for time-based verification, and the payment amount can be used as a comparison measure to improve matching accuracy.

[0087] Additionally, the payment data linkage receiving unit (210) can receive data through an encrypted channel and perform data integrity verification to minimize the possibility of tampering or loss during the transmission process. For example, TLS-based secure communication, message integrity hash verification, and retransmission request processing may be performed. Accordingly, the payment data linkage receiving unit (210) can play an important role in improving data accuracy and matching reliability throughout the system (1000) by receiving payment transaction data, including unique identification information that can distinguish the transaction, payment date and time, and payment amount information, on a high-reliability basis.

[0088] The above payment data verification unit (220) can select at least one of unique identification information, payment date and time, and payment amount that can distinguish the transaction of the payment transaction data received through the payment data linkage receiving unit (210) as a verification criterion, and perform at least one of time verification, amount verification, and terminal identification information-based verification according to the selected verification criterion to generate verification result data for the payment transaction data.

[0089] More specifically, the payment data verification unit (220) may preferentially select at least one of the unique identification information, payment date and time, and payment amount that can distinguish the transaction included in the payment transaction data received through the payment data linkage receiving unit (210) as a verification criterion, and perform a verification procedure to determine whether the payment data corresponds to an actual donation act based on the selected criterion. For example, since the unique identification information that can distinguish the transaction is a unique payment identification value including an approval number assigned by an external payment system, the payment data verification unit (220) may determine the possibility of forgery or tampering through the format suitability of the unique identification information, reuse status, and inspection by the issuing institution, and may immediately generate verification failure data if the unique identification information is abnormally repeated or provided in an unauthorized format.

[0090] Additionally, the payment data verification unit (220) performs time verification based on the payment date and time, and can apply an acceptable time deviation between the time of donor input and the time of payment occurrence as a judgment criterion. Generally, since payment occurs immediately after the donor scans the QR code or enters the UI, the system (1000) can determine payment data that occurred at an excessively early or delayed time as a failure to be verified. For example, if there is donation data entered with the same unique identification information but the payment date and time is several hours or days earlier or later, the payment data verification unit (220) can classify the payment data as being in a pending state and automatically induce an administrator verification step or a rematching procedure.

[0091] Additionally, the payment data verification unit (220) can perform payment amount verification and determine whether the amount value included in the payment data corresponds to a normal donation pattern by referring to the donation amount entered by the donor, the predefined minimum donation amount per campaign, or information on the designated amount range. For example, in a general fundraising campaign, if the donation unit is limited to 1,000 won or 10,000 won, the payment amount may be classified as a verification failure or an additional verification target if it is an inaccurate decimal amount or an unintended high amount.

[0092] Additionally, the payment data verification unit (220) performs verification based on terminal identification information to detect security risks when suspicious pattern payments occur repeatedly on the same terminal or when the same donation activity is input at an abnormal speed on different terminals. For example, if payments occur excessively frequently on the same terminal with the same unique identification information, the system (1000) automatically increases the risk level of the data, and the payment data verification unit (220) tags it as a suspicious transaction and transmits it to the donation activity analysis unit (300) as a request for additional verification.

[0093] Additionally, the payment data verification unit (220) can generate verification result data for payment transaction data by combining the results of unique identification information-based verification, time verification, amount verification, and terminal identification information verification, and can calculate a reliability score by assigning weights to each verification item. For example, if the unique identification information and the payment date and time match exactly but the amount is outside the normal value range, the reliability can be calculated as an intermediate level and can be transmitted including a state that additional verification by an administrator is required.

[0094] Accordingly, the payment data verification unit (220) can verify the authenticity and suitability of the received payment transaction data in a multifaceted way, thereby dramatically improving the matching accuracy between the donation input data and the payment transaction data, and the result data can be used as a key verification measure to prevent problems such as data errors, fraudulent use, and duplicate donations in advance during the entire donation data processing process within the system (1000).

[0095] The above payment data exception processing unit (230) may transmit a re-collection request signal for payment transaction data to the payment data linkage receiving unit (210) or generate administrator verification request information when inaccurate data is detected in the verification result data of the payment data verification unit (220).

[0096] More specifically, the payment data exception processing unit (230) can automatically detect payment transaction data items that fall outside the normal range among the verification result data generated by the payment data verification unit (220), and classify the data as an exception situation if the likelihood of matching is low or if manipulation or transmission failure is suspected. This exception classification can be based on various risk factors such as errors in the unique identification information format, extreme deviations in payment time, abnormal payment amounts, and discrepancies in terminal identification information, and weight-based rules based on payment methods, donation campaign characteristics, and past data patterns can be applied. For example, if multiple approval failure data are received repeatedly over a short period of time from the same payment terminal, the payment data exception processing unit (230) can automatically generate an exception detection signal to take preemptive action.

[0097] Additionally, if inaccurate payment transaction data is detected, the payment data exception processing unit (230) may request the retransmission of the payment data by transmitting a recollection request signal to the payment data linkage receiving unit (210). At this time, the recollection request signal may include a transaction ID, terminal ID, error cause code, etc., to support the external payment system in performing accurate data retransmission. Recollection may be performed using an immediate retry method or a delayed retry method based on a set period, and if the retransmitted data is determined to be normal, it may replace the existing verification failure data to enable normal processing by the donation activity analysis unit (300). For example, if approval completion data is delayed due to network congestion, a recollection request is automatically triggered, and the data may eventually be matched with normal data within an appropriate time.

[0098] Additionally, the payment data exception processing unit (230) can generate administrator verification request information if data errors are not resolved even with re-collection or if serious security risks are detected. This information can be transmitted to an administrator terminal (40) or operator console within the system (1000) and can be used for manual verification of problematic data and the establishment of correction strategies. The administrator verification request information includes the type of suspected error, risk level, time of occurrence, and the availability range of related donor identification information, thereby supporting the administrator in taking measures such as contact verification, transaction blocking, and resetting subsequent matching conditions as needed. For example, if the same unique identification information is used almost simultaneously in multiple regions, the administrator verification request information may indicate a high probability of a security breach, allowing for immediate on-site verification procedures to be implemented.

[0099] Additionally, the payment data exception processing unit (230) can accumulate and manage the processing history of data classified as exceptions and analyze the types of recurring occurrences to contribute to improving the overall data quality of the system (1000). This historical data can be linked with the donation activity analysis unit (300) and the donation history management unit (400) to be used for updating automatic matching policies and security policies, and can block errors of the same type in advance or apply automatic mitigation policies if they recur. For example, if a payment amount error that occurs repeatedly for a specific campaign is detected, improvements to the donation amount input method or supplementation of the basic guidance message can be automatically applied in the campaign UI.

[0100] Accordingly, the payment data exception processing unit (230) can quickly correct errors, delays, and inconsistencies that may occur during the payment data collection stage and automatically identify situations requiring human intervention, thereby maximizing the stability and accuracy of subsequent data processing processes and further enhancing the matching reliability, payment data integrity, and security of the entire system (1000).

[0101] Meanwhile, the payment data collection unit (200) can receive payment transaction data generated from various payment methods, such as card payment, account transfer, simple payment, NFC-based contactless payment, and virtual account payment. Since the approval number structure, payment date and time format, and amount field structure may differ for each payment method, the payment data linkage receiving unit (210) can convert the data into a standardized payment transaction data format by applying data conversion rules for each payment method.

[0102] In addition, the payment data collection unit (200) can receive encrypted approval information by using a security API provided by an external payment system, such as a PG company, a card company, a financial institution, or a simple payment service provider. For example, in the case of a simple payment service, token-based terminal identification information and user authentication result data can be provided together and used as auxiliary verification information to improve the accuracy of the matching analysis.

[0103] Additionally, the payment data collection unit (200) may be linked with a dedicated payment terminal device (e.g., kiosk, tablet payment terminal, mobile card reader, etc.) installed at the donation site, so that on-site payment information can be transmitted to the system (1000) without delay. For example, when NFC-based payment approval is made at a kiosk terminal, unique identification information and terminal identification information that can distinguish a transaction including an approval number may be automatically collected and provided as reference data to the donation activity analysis unit (300).

[0104] The donation activity analysis unit (300) can generate donation activity information by analyzing the association between the donation input data received from the input data receiving unit (100) and the payment transaction data collected from the payment data collection unit (200).

[0105] To this end, the donation activity analysis unit (300) may include an automatic matching analysis unit (310), a matching judgment unit (320), a data transmission unit (330), and a matching key determination unit (340), as illustrated in FIG. 5.

[0106] The above automatic matching analysis unit (310) can generate matching result data by analyzing at least one corresponding relationship among unique identification information, payment date and time, payment amount, and terminal identification information that can distinguish transactions between donation input data received from the input data receiving unit (100) and payment transaction data collected from the payment data collection unit (200).

[0107] More specifically, the automatic matching analysis unit (310) can quantitatively analyze the correspondence with at least one of the unique identification information, payment date and time, payment amount, and terminal identification information that can distinguish transactions within the payment transaction data collected by the payment data collection unit (200), based on the unique identification information, donation input time information, and input terminal characteristic information that can distinguish transactions within the donation input data received from the input data receiving unit (100). The automatic matching analysis unit (310) can generate matching candidates to determine the possibility of a relationship between each data element and can first extract data sets presumed to be the same payment activity using whether the unique identification information matches as a primary criterion. At this time, if the unique identification information matches completely, it can be classified as a direct match with high reliability, and if the unique identification information is empty or partially matches, the possibility of matching can be evaluated by sequentially applying auxiliary rules such as time-based matching, amount-based matching, and terminal-based matching.

[0108] Additionally, the automatic matching analysis unit (310) can analyze the proximity of the payment date and time to determine whether the time difference between the data falls within a range that aligns with the purpose of the donation. For example, since it is common for a payment to occur immediately after a donor enters donation information via QR code scanning or a kiosk UI, the allowable error range between the payment date and time relative to the input date and time can be defined in advance, and data that meets this range can be matched preferentially. Conversely, if it falls outside the allowable range, it can be determined that the matching reliability is low and pending data can be generated.

[0109] Additionally, the automatic matching analysis unit (310) can apply a payment amount-based matching algorithm to check whether the donation amount selected or presented at the donation input stage is the same as the payment amount or is within a predefined allowable error range. For example, if a fixed donation amount or a representative amount range is set for each campaign, a matching score may be calculated low if the payment amount does not fall within that range, and conversely, if the payment amount matches a specific pattern, the reliability score may be adjusted upward. Through this, amount errors, incorrect input, fraudulent payments, etc., can be excluded early.

[0110] Additionally, the automatic matching analysis unit (310) can determine consistency between donation data and payment data entered from the same terminal by utilizing payment terminal identification information. For example, if a donation is entered from a specific facility or mobile terminal, the reliability of matching based on the same source can be strengthened by checking whether the unique identifier of the terminal (MAC address, terminal number, etc.) is also included in the payment data. If the same payment data occurs almost simultaneously from terminals located in different regions, the automatic matching analysis unit (310) can classify this as an abnormal pattern and automatically trigger a re-verification step.

[0111] Additionally, the automatic matching analysis unit (310) can integrate the matching results of each of the unique identification information, payment date and time, payment amount, and terminal identification information into a single reliability score and generate matching result data based on the integrated reliability score. At this time, a pre-set importance weight may be assigned to each element, and the weight may be dynamically adjusted according to the operating environment of the system (1000), specific campaign characteristics, and the results of the analysis of exception occurrence patterns. For example, in an environment with low network quality, time discrepancies are expected, so the payment date and time weight may be temporarily lowered, and the weight of the unique identification information or terminal information may be strengthened.

[0112] Accordingly, the automatic matching analysis unit (310) can secure a much higher level of judgment accuracy compared to single-criteria-based matching by applying various verification criteria in combination, reduce matching failure data to minimize the burden of manual verification, and improve the data stability and reliability of the donation history generation and donation receipt issuance processing throughout the system (1000).

[0113] Meanwhile, the automatic matching analysis unit (310) can extract at least one of the payment occurrence location information, payment terminal type information, and payment pattern information included in the payment transaction data as a feature quantity, compare and analyze the extracted feature quantity to determine whether there is a match between the donation input data and the payment transaction data, and generate donation activity information including the determination result.

[0114] More specifically, the automatic matching analysis unit (310) can perform a much more sophisticated matching determination than simple unique identification information or amount information-based matching by additionally collecting and analyzing additional information included within the payment transaction data. In particular, at least one of the payment occurrence location information, payment terminal type information, and payment pattern information can be extracted as a feature to strengthen the behavioral clue-based association between the donation input data and the payment transaction data.

[0115] For example, payment occurrence location information may include GPS-based coordinates, indoor positioning-based zone IDs, terminal connection AP identification information, and location codes of terminals installed at each branch, and the automatic matching analysis unit (310) can determine whether the location information is close to the location information at the time of donor input and calculate the geographical proximity. If a donor scans a QR in the lobby of a specific hospital and makes a payment immediately, a high matching reliability may be assigned to the payment made at a terminal within the same hospital. Conversely, if a payment is made at a location hundreds of kilometers away, the automatic matching analysis unit (310) may determine this as an abnormal pattern and request additional verification.

[0116] Furthermore, payment terminal type information can reflect the characteristics of the terminal where the payment transaction occurred, such as fixed kiosks, portable POS systems, NFC-based mobile terminals, and online payment gateways. High reliability can be assigned if terminal characteristics identical to the channel used during the donation input process are detected. For example, high matching performance can be secured if a payment is recognized from the same kiosk terminal as the donation information entered by the donor via the kiosk UI on-site. Conversely, if the donation information was entered on-site but the payment is processed on an online payment platform, a hold can be applied to reflect the possibility of a behavioral discrepancy.

[0117] Additionally, the automatic matching analysis unit (310) can identify repetitive behavioral characteristics by analyzing payment pattern information by donor or by campaign. The payment pattern information may consist of the preference for donation amount, the average time interval between input and payment, and the frequency of use of payment methods, and if an abnormal pattern is detected by comparing it with the donor's past donation records, the risk level may be adjusted upward. For example, if a specific donor has been donating the same amount online every week but suddenly a high-value payment occurs at a field terminal, the automatic matching analysis unit (310) may determine that the data is data with a potential for error that occurred regardless of the donation intention and perform auxiliary verification.

[0118] Additionally, the automatic matching analysis unit (310) can calculate a single matching reliability score by integrating the location-based analysis results, the terminal type-based analysis results, and the payment pattern-based analysis results. At this time, weight-based importance may be assigned to each feature quantity, and the weights may be dynamically adjusted according to the operational characteristics of a specific campaign or the analysis results of past matching failure types. Through this analysis, the system (1000) can be designed to make different judgments regarding the same event depending on the timing, environment, and changes in the usage channel.

[0119] Additionally, the automatic matching analysis unit (310) can determine whether a match exists based on the final result of comparing feature quantities and generate donation activity information including the result of the determination. The generated donation activity information may include result data such as whether the match was successful, the reliability level, whether reference verification is required, and the data difference value. This information can be transmitted to the donation history management unit (400) and stored as core data constituting donation history information, and can also be applied as basic data for generating donation receipt data used by the receipt issuance unit (500) and for generating donation receipt documents or data files for batch issuance of electronic donation receipts. Additionally, it can optionally be applied as basic data for processing data for external submission used by the format conversion processing unit (600) and the submission result transmission unit (700).

[0120] Accordingly, the automatic matching analysis unit (310) implements multidimensional behavior-based matching technology rather than simple string comparison, thereby blocking the inflow of abnormal payment data in advance and ensuring a highly reliable donation data flow in which the donor's actual behavior and payment results are naturally connected, and maximizing the matching accuracy, security, and donation processing efficiency of the system (1000).

[0121] The above matching determination unit (320) can provide a matching retry request or manual matching request interface based on the matching result data generated by the automatic matching analysis unit (310).

[0122] More specifically, the matching judgment unit (320) may repeatedly perform an automatic matching procedure between donation input data and payment transaction data based on the matching reliability, judgment status, and whether an error has occurred in the matching result data calculated by the automatic matching analysis unit (310), or may provide a manual matching request interface for the administrator or donor of the system (1000). The matching judgment unit (320) may automatically apply a retry policy for matching failures or matching cases with low reliability, and, for example, if data that was temporarily suspended due to a large discrepancy between the donation input time and the payment date and time is newly collected with appropriate payment data after a certain period of time, automatic rematching may be performed.

[0123] In addition, the matching judgment unit (320) may configure an environment in which an administrator can directly determine whether to match by providing a manual matching request interface when there is a possibility of error in the automatic matching result or when additional verification data (e.g., identity authentication result data) needs to be checked. At this time, the manual matching request interface can visually display a list of matching candidates, a risk level, matching failure factors, reference data (e.g., time information, amount comparison results, terminal information, etc.), thereby supporting the administrator in making an accurate judgment.

[0124] Additionally, the matching decision unit (320) can record and analyze retry results, administrator manual matching results, final confirmed matching results, etc., so that the matching algorithm of the automatic matching analysis unit (310) can be continuously learned. For example, if there is a specific type of data pattern in which manual matching is repeatedly approved by an administrator, the matching decision unit (320) can transmit a policy update to the automatic matching analysis unit (310) to increase the matching weight for the pattern.

[0125] Additionally, the matching decision unit (320) can store response policies for each matching failure cause code and apply an automatic action flow suitable for each failure type. For example, it can be configured to automatically branch to a request for donor re-entry for missing unique identification information, a request for re-collection for payment data delay, and a request for administrator verification for amount discrepancy. This can reduce unnecessary waiting time and increase the overall matching processing rate.

[0126] Additionally, the matching judgment unit (320) can perform data synchronization with the matching policy update unit (450) and the donation history management unit (400) so that the result determined by manual matching is reflected in the future automatic matching rule adjustment. In this process, the matching result data is recorded as a log and subsequently used as retraining data so that the matching accuracy of the system (1000) can be continuously improved.

[0127] Accordingly, the matching judgment unit (320) can flexibly handle exception cases that may be missed in automatic matching, and by efficiently selecting data that requires intervention from an administrator, it can minimize the burden of manual verification and contribute to improving the matching reliability and processing efficiency within the system (1000).

[0128] The above data transmission unit (330) can transmit the matching result data generated by the automatic matching analysis unit (310) to the donation history management unit (400).

[0129] More specifically, the data transmission unit (330) may manage a transmission path based on an internal data bus or a secure communication protocol to reliably transmit the matching result data generated by the automatic matching analysis unit (310) to the donation history management unit (400). The data transmission unit (330) may first check the data consistency of the essential fields (e.g., whether the matching is successful, the matching reliability, the comparison criteria item information, etc.) included in the matching result data, and control the transmission to the next stage module only if no data format errors or missing items are detected. For example, if the matching result data generated by the automatic matching analysis unit (310) does not include a matching reference key, the data transmission unit (330) may load the result data into a temporary storage area and automatically generate a supplement request signal.

[0130] Additionally, the data transmission unit (330) can apply a data tamper prevention function to the transmitted matching result data to ensure integrity during the internal transmission process of the system (1000). At this time, the data transmission unit (330) can perform security verification procedures such as checksum verification and encryption token-based integrity verification, and in particular, the matching result linked to donor identification data and authentication data can be transmitted in a masked or de-identified state to satisfy personal information protection requirements. For example, data exposure can be prevented by including only a part of the unique identification information or transmitting it in the form of a hash value instead of directly exposing the entire phrase.

[0131] Additionally, the data transmission unit (330) can determine the transmission priority of the matching result data and perform branching control so that the matching successful data is immediately transmitted to the donation history management unit (400), and the matching deferred or failed data is transmitted including metadata of the confirmed status. Through this, normal data requiring urgency for the creation of donation history and the issuance of donation receipts can be transmitted to the next stage without processing delay. For example, data with a high degree of matching between the payment amount and time can be automatically prioritized for processing to prevent delays in the donation receipt creation process.

[0132] Additionally, the data delivery unit (330) can detect in real time transmission failures, delays, or response timeouts occurring during the transmission process and perform a retransmission request or an alternative path transmission procedure. For example, if data reception is delayed due to a temporary system load of the donation history management unit (400), the data delivery unit (330) can prevent data loss by temporarily storing the data in a transmission queue and then performing retransmission at regular intervals.

[0133] Additionally, the data transmission unit (330) tracks whether the matching result data has been received and transmits the success or failure of data reception to the automatic matching analysis unit (310), or, if necessary, loads it into a log for use in post-analysis. This transmission history data can be used as important data for checking the operational status of the system (1000), analyzing the matching processing rate, and establishing policies for improving service quality.

[0134] Accordingly, the data transmission unit (330) can stably and efficiently transmit the matching result data produced by the automatic matching analysis unit (310) to the donation history management unit (400), thereby minimizing delays and errors in the generation of donation history and subsequent issuance of donation receipts, and can perform a key connection role that improves the quality of data flow throughout the system (1000).

[0135] The above matching key determination unit (340) can set the institution-specific member identifier information included in the donation input data as a key matching key applied to the analysis of the correspondence relationship between the donation input data and the payment transaction data.

[0136] More specifically, the matching key determination unit (340) can establish key matching criteria for analyzing the correspondence between the donation input data and the payment transaction data based on the institution-specific member identifier information included in the donation input data. The institution-specific member identifier may consist of a unique donor number, membership card number, volunteer registration number, barcode or RFID-based identification value, etc., that are internally managed by each institution, such as a religious organization, a social welfare institution, a civic group, or a hospital sponsorship association. This identification information can be utilized as an important data element that can clearly link the identity and purpose of donation of a donor who continuously performs donation activities at a specific institution.

[0137] Additionally, the matching key determination unit (340) can analyze the format and structure of the member identifier information for each institution and designate it as a major matching key to be compared first during the automatic matching analysis process of the donation activity analysis unit (300). For example, in the case of a church offering system, since the sponsor number assigned to each offering envelope is fixed, that number can be applied as the highest priority matching key, and in the case of a hospital charity program, the patient registration number or the sponsor unique code can be set as the priority matching standard. Through this, even if other matching conditions, such as missing unique identification information or payment data delays, are not temporarily satisfied, a matching result with high reliability can be obtained through the member identifier for each institution.

[0138] Additionally, the matching key determination unit (340) may set one or more combinations of identifiers as matching keys according to the institution's policy when various types of identifiers exist within the same institution. For example, in a specific sponsorship association, a sponsorship zone number may be additionally assigned to regular sponsors along with a unique ID, and by combining these, the matching accuracy can be increased in situations where multiple candidates are detected. The criteria for combining matching keys may be dynamically adjusted according to the institution's authentication policy, past matching failure logs, and security level requirements.

[0139] Additionally, the matching key determination unit (340) can learn exception patterns found during the matching process and continuously optimize the priority of matching keys based on member identifiers by institution. For example, in an environment where the distinction of terminal identification information becomes unclear due to the shared use of terminals by donors of a specific institution at the same event venue, automatic correction can be performed by strengthening the weight of matching based on member identifiers by institution and relatively lowering the weight of matching based on time information.

[0140] Additionally, the matching key determination unit (340) may configure an auxiliary matching system to prevent the matching process from being interrupted by setting a unique donor identifier or unique identification information capable of distinguishing transactions as an alternative matching key when there is no member identifier in the donation input data. In this case, the alternative matching key may be assigned a low priority based on risk to minimize the possibility of misjudging the donor.

[0141] Accordingly, the matching key determination unit (340) sets appropriate matching criteria based on member identifier information for each institution, thereby minimizing data errors occurring in various payment environments and input channels, stably identifying the actual subject of the donation act, and playing an important role in improving the matching accuracy and reliability of the system (1000).

[0142] The above donation history management unit (400) can generate donation history information based on donation activity information generated by the donation activity analysis unit (300), store and manage the generated donation history information in an integrated manner, and generate donation receipt data corresponding to the donation activity information.

[0143] To this end, the donation history management unit (400) may include a donation history generation unit (410), a multi-tenant management unit (420), a donation history portal provision unit (430), a matching exception management unit (440), a matching policy update unit (450), and a correction result reflection unit (460), as illustrated in FIG. 6.

[0144] The donation history generation unit (410) can generate donation history information based on donation activity information generated by the donation activity analysis unit (300), and store the generated donation history information to provide base data for subsequent processing.

[0145] More specifically, the donation history generation unit (410) can generate donation history information corresponding to the donation act actually performed by the donor based on the matching result data and donation act information transmitted from the donation act analysis unit (300). The donation history generation unit (410) can store essential attributes for legal and financial proof of the donation act by structuring data, including the donor's identification token, payment amount, time of payment, donation purpose code, information on the donation campaign participated in, and unique identification information that can distinguish the transaction. For example, if the donor participated in a specific hospital sponsorship program, the institution ID of the hospital, designated donation amount, donation time, unique identification information that can distinguish the transaction, and the matching judgment reliability can be recorded as components of the donation history.

[0146] Additionally, the donation history generation unit (410) can classify and store donation history information according to the type of donation activity and payment method. Donation data entered through various participation channels, such as online payment-based donations, on-site kiosk-based donations, and QR code-based mobile donations, can serve as important information for analyzing donation channels and establishing operational policies for each institution, and the donation history generation unit (410) can identify and classify each channel and accumulate it in a database. For example, if the same donor repeatedly performs regular donations through a mobile UI, the pattern can be automatically recognized as a continuous donation history and reflected in the long-term donor classification policy.

[0147] Additionally, the donation history generation unit (410) can store status information generated from the donation behavior analysis results, such as the matching reliability grade, whether exception processing is required, and whether administrator verification is necessary. This can serve as key data referenced in subsequent steps for determining whether to generate donation receipt data, monitoring for fraudulent use, determining requests for manual verification, and preparing for receipt issuance processing. For example, donation history with low matching reliability can be automatically included in the exception review list and configured to be viewable on the administrator terminal (40).

[0148] Additionally, the donation history generation unit (410) can quickly respond to various search and aggregation requests by indexing the stored donation history information by time, institution, and donor. For example, requests such as monthly donation statistics, the cumulative status of donation amounts for a specific institution, and inquiries into the details of donation receipt issuance targets by donor can be processed immediately. This structured storage method can provide a foundation for the system (1000) to perform donation status monitoring, policy decision support, and performance analysis in real time.

[0149] In addition, the donation history generation unit (410) can store sensitive data by de-identifying it in order to comply with the legal retention period of donation data and meet personal information protection requirements, and can manage separate operational policies between data requiring long-term storage and data that is temporarily stored and then discarded. For example, the identity authentication token can be stored only in an encrypted state to prevent data leakage, and can be processed so that it can be compared without decryption during the matching verification step only when necessary.

[0150] Accordingly, the donation history generation unit (410) can secure the legal validity of donation data and the appropriateness of financial processing by accurately converting the donor's actual donation act into data, and can secure the consistency of donation receipt data generation required for automatic generation of donation receipt documents or generation of data files for batch issuance of electronic donation receipts, and can stably generate and provide core data assets that serve as the basis for the entire process of utilizing donation data within the system (1000).

[0151] The above multi-tenant management unit (420) can integrate and manage donation history information generated in the donation history generation unit (410) on a multi-tenant basis so that multiple non-profit organizations can manage it in the same platform environment.

[0152] More specifically, the multi-tenant management unit (420) can provide separation and integration management functions so that donation history information generated by the donation history generation unit (410) can be managed independently by multiple non-profit organizations in an environment where they share the same system (1000) platform. The multi-tenant management unit (420) can operate data access rights, storage areas, and policy settings separately on a tenant (organization) basis, and can apply logical data isolation or storage partitioning technologies to prevent data mixing or exposure between organizations. For example, even if Organization A and Organization B use the same system (1000), the administrator of Organization A can be configured so that they cannot access the donation history information of Organization B.

[0153] Additionally, the multi-tenant management department (420) can apply customized data management policies to reflect differences in the operational policies and donation history utilization methods of each institution. Since the method of issuing donation receipts, the donation history approval procedure, the donor classification policy, and the donation campaign code system may differ by institution, the multi-tenant management department (420) can identify these differences and manage the donation history data so that it is stored in a structure suitable for the policy of the institution. For example, one institution may apply an automatic payment renewal policy to regular sponsorship data, while another institution may require a separate verification procedure for each payment, and the multi-tenant management department (420) can control this through system settings.

[0154] Additionally, the multi-tenant management unit (420) can set unique administrator accounts, access control rules, and audit log policies for each institution. This provides an environment where the security and consistency of the system (1000) platform are maintained while each institution maintains an independent operating system. For example, if a specific institution sets a double approval policy for high-risk data (large donations, donations from overseas, etc.), the multi-tenant management unit (420) can apply this condition only to the administrator account of that institution and process it so as not to affect other institutions.

[0155] Additionally, the multi-tenant management unit (420) can organize data inquiry and analysis authority in a multi-layered structure so that the aggregation and analysis of donation history data can be performed by institution or on a whole platform basis. For example, the platform operator can view total donation statistics for a specific period, but may be restricted from accessing sensitive data such as individual donor information. On the other hand, each institution manager may be granted authority to view and analyze donation data within their own institution in detail.

[0156] In addition, the multi-tenant management unit (420) can automate the management of data storage capacity by institution, the setting of backup policies, and the adjustment of log retention periods, thereby providing a stable data operation environment for the entire platform. Through this, each institution can focus on operating donation services without the burden of infrastructure management. For example, when a campaign is executed during which donations surge during a specific period, the data processing capacity of the relevant institution can be automatically temporarily expanded, and restored to its original state after the campaign ends.

[0157] Accordingly, the multi-tenant management department (420) can maximize the scalability and operational efficiency of the donation service by providing an environment in which multiple non-profit organizations can use the same system (1000) platform together while the donation history data of individual organizations is safely protected and customized policies can be applied.

[0158] The above donation history portal providing unit (430) provides donation history information managed by the multi-tenant management unit (420) so that it can be viewed through a donor terminal (20) or an administrator terminal (40), and provides correction request information so that it can be entered through a correction request input UI, and can be linked with a personalized information providing service that induces future donation activities by analyzing the donor's past donation history, preferred donation fields, and region-based social contribution needs.

[0159] More specifically, the donation history portal providing unit (430) can provide a user interface (UI) and a service access environment so that donation history information managed by the multi-tenant management unit (420) can be viewed in real time through a donor terminal (20) or an administrator terminal (40). The donation history portal providing unit (430) can set different screen configurations, data display ranges, and access rights depending on the user type, and, for example, can perform differentiated access control so that the donor terminal (20) can only view its own donation history, while the administrator terminal (40) can access the overall donation status and detailed donation history within the institution.

[0160] In addition, the donation history portal provider (430) can enhance user convenience by providing various sorting criteria (e.g., donation date, donation amount, campaign name, etc.), filtering options (e.g., by month, by institution, by payment method, etc.), and search functions (e.g., donation receipt identification information, unique identification information that can distinguish transactions, etc.) for the viewable donation history information. For example, it can support filtering only the donation history made by a donor in a specific year so that it can be immediately used as data for issuing donation receipts.

[0161] Additionally, the donation history portal provider (430) can display the donation processing status, such as matching reliability, whether verification is required, receipt issuance availability, or issuance processing status, along with the displayed donation history. Warning displays, color coding, and notification messages can be applied so that the donor can easily recognize items requiring verification, and the administrator terminal (40) can be provided in the form of a management dashboard that allows for quick classification and verification of cases where errors occurred or cases awaiting review.

[0162] Additionally, the donation history portal provider (430) provides a correction request input UI, allowing the donor to directly input correction request information (e.g., reason for error, item for change, etc.) if an error is suspected in their donation history or if they need to change their personal information. For example, if an error in inputting unique identification information that distinguishes a transaction or an incorrect entry of the payment amount affects the matching result, the donor can immediately submit a correction request to wait for review by an administrator. At this time, the correction request information can be processed under a status management system that includes a correction request ID, status (e.g., waiting, approved, rejected), and information of the reviewer in charge.

[0163] In addition, the donation history portal provider (430) provides additional functions such as downloading donation receipt documents, requesting the issuance of donation proof materials, and viewing donation participation history statistics, enabling donors to process various administrative procedures on a single platform. For example, donors can download donation proof data required for year-end tax settlement with a single request, and administrators can manage the status of donation receipt issuance by institution.

[0164] In addition, the donation history portal provision unit (430) can be designed to allow disabled, elderly, and foreign donors to easily use the service by taking into account multilingual and accessibility standards. Accessibility features such as voice guidance, text enlargement, high-contrast UI, and screen reader compatibility may be applied.

[0165] In addition, the donation history portal provider (430) can propose donation campaigns with high social impact or non-profit organizations in fields of interest to the donor by applying a donor-customized AI recommendation algorithm based on the donor's donation history information and social contribution activity history. At this time, the recommendation algorithm can calculate recommendation priorities by multidimensionally analyzing the donor's age group, donation frequency, distribution of donation amounts, preference by campaign, and region-based social contribution needs. For example, for a donor with a high history of participation in donations in the environmental field, carbon reduction projects or donation campaigns in the disaster relief field may be recommended at the top.

[0166] In addition, the donation history portal provider (430) can support donors in naturally continuing their donation activities by sending AI-based reminder notifications based on specific triggers, such as year-end tax settlements, anniversaries, or the occurrence of social issues. These reminder information can automatically optimize the sending cycle, message content, and recommended projects by comprehensively considering the donor's past donation patterns, preference settings, organization favorite information, and donation cycle analysis results. Furthermore, the donation history portal provider (430) can quantitatively reflect the donor's good deeds by awarding points based on the donation amount, donation frequency, and matching reliability. The awarded points are accumulated and managed, and can be linked to donor grade information, the display of social contribution certification badges, or the provision of benefits with affiliated services.

[0167] In addition, the donation history portal provider (430) can ensure the sustainability and scalability of donation participation by providing a point-based ranking system, a donation challenge and campaign participation reward function, and a community-based social contribution feedback function.

[0168] Accordingly, the donation history portal provision unit (430) can improve data accessibility and convenience for donors and administrators, increase the transparency and reliability of donation data, and streamline the processing of correction requests and proof issuance, thereby comprehensively improving the quality of the donation service of the system (1000).

[0169] Meanwhile, the donation history management unit (400) can generate hash values ​​for key attribute values ​​of the donation history data (e.g., donor identification information, donation amount, donation date, unique identification information that can distinguish transactions, matching reliability status, etc.) and record the generated hash values ​​on a blockchain network in order to prevent forgery and tampering and to ensure transparency regarding the generated donation history information. The blockchain network can be implemented as a distributed ledger structure based on public nodes or jointly operated nodes of institutions. In addition, the hash values ​​recorded on the blockchain can be compared in real-time with the donation history information viewed by the donor through the donation history portal, and if it is determined whether the stored data has been changed, a warning information can be displayed and an administrator verification procedure can be automatically performed. For example, if the unique identification information that can distinguish transactions is changed after the fact or the amount field is forged or tampered with, the fact of inconsistency with the blockchain record can be detected immediately. In addition, the donation history management unit (400) can generate a QR code or a blockchain authentication token for verifying the donation history and provide it to the donor. Donors can access an external verification page via the provided QR code to directly confirm that their donation history is blockchain-based authenticated data, which can strengthen trust in donation transparency.

[0170] The above matching exception management unit (440) can separately store matching failure items among the donation activity information generated by the donation activity analysis unit (300) and transmit information regarding confirmation or correction request guidance for matching failure items to the donation history portal provision unit (430).

[0171] More specifically, the matching exception management unit (440) can manage donation activity information that has been successfully matched separately from donation activity information that has been successfully matched by selecting only the items marked as matching failures based on the judgment result of the automatic matching analysis unit (310) from the donation activity analysis unit (300) and storing them in a separate exception data area. The matching exception management unit (440) can store metadata for each matching failure item, such as donation input data, payment transaction data, applied matching criteria (unique identification information that can distinguish the transaction, payment date and time, payment amount, terminal identification information, etc.), matching failure reason code, number of automatic matching attempts, and matching reliability score at the time, so that it can provide sufficient supporting information necessary when an administrator or donor performs a verification and correction request later. For example, in the case where the unique identification information that can distinguish the transaction matches but the payment date and time exceeds the allowed time window and is processed as a matching failure, the matching exception management unit (440) can classify and store the item as an exception of the "time standard mismatch" type.

[0172] Additionally, when the matching exception management unit (440) receives matching result data transmitted from the donation activity analysis unit (300), it can manage matching success items and matching failure items by separating them into status-based storage structures such as an exception queue and a review waiting queue. These exception queues may include items that exist in PG settlement data but do not have donor input data, items where donor input data exists but payment transaction data has not yet been collected, or items that do not meet automatic matching criteria because the amount, time, or terminal information only partially matches. The matching exception management unit (440) can set retry conditions for these exception items (e.g., re-collection of payment data after a certain period of time, re-analysis after uploading a batch file, etc.) and manage a flag indicating whether the item is subject to rematching, thereby preparing for the subsequent automatic rematching procedure to be efficiently performed in the system (1000).

[0173] Additionally, the matching exception management unit (440) can determine whether there is a need for a donor or manager to be aware of a separately stored matching failure item, and, depending on the result, generate guidance information to be delivered to the donation history portal provision unit (430). At this time, the guidance information may include summary information of the matching failure item (e.g., planned donation amount, expected donation date, organization name, etc.), types of reasons for matching failure (e.g., mismatch in unique identification information, difference in amount, exceeding time range, mismatch in terminal information, etc.), correction actions that the donor can perform (e.g., re-entering unique identification information, correcting the donation date selection, verifying contact information, etc.), and whether a manager review is required. For example, the matching exception management unit (440) can deliver a correction request guidance message to the donation history portal provision unit (430) in the form of, "There is a payment transaction that was not matched due to the failure to enter unique identification information, so please enter the unique identification information on the correction request screen."

[0174] Additionally, the matching exception management unit (440) can be designed to be linked with the correction request input UI provided by the donation history portal provision unit (430), and can provide reference data for the configuration of a detailed screen to be displayed when a matching failure item is selected on the donor terminal (20) or the administrator terminal (40). In this process, the matching exception management unit (440) distinguishes between fields that can be corrected (e.g., unique identification information that can distinguish a transaction, donation date, selection of institution, etc.) and fields that can only be changed by the internal logic of the system (1000) (e.g., matching reliability, exception status code, etc.) for each exception item and displays them as flags, and can support the donation history portal provision unit (430) in clearly limiting the range of input possible by the user. For example, in the administrator-only screen, functions such as adjusting the payment amount or forcing the selection of a specific matching candidate may be allowed, but in the general donor screen, it may be configured so that only the re-entry of unique identification information or correction of contact information is allowed.

[0175] In addition, the matching exception management unit (440) can go beyond simply displaying information on the screen regarding confirmation or correction requests for failed matching items, and can be utilized in conjunction with conditions for sending notification messages. For example, if unmatched exception items accumulate over a certain period or if a time arrives when the demand for issuing donation receipts increases, the matching exception management unit (440) can transmit information requesting the sending of push notifications, text messages, KakaoTalk notifications, etc., to the donation history portal provider (430) based on the list of exception items. Through this, the donor can recognize early on potential situations where their donation may not be reflected in the issuance of proof, and can immediately submit a correction request on the portal screen.

[0176] Accordingly, the matching exception management unit (440) separately structures and stores items marked as matching failures among the donation activity information generated by the donation activity analysis unit (300), and provides appropriate verification or correction request guidance information for the items to the donation history portal provision unit (430), thereby enabling systematic management of exception situations such as matching errors, omissions, and duplicates within the system (1000) and supporting donors and managers to cooperate to ensure the final consistency of the donation history.

[0177] The above matching policy update unit (450) can record matching status change information stored in the matching exception management unit (440) as a log, and automatically update the matching reliability calculation criteria and exception handling rules that configure automatic matching criteria based on the recorded log information.

[0178] More specifically, the matching policy update unit (450) can continuously collect matching status change information stored by the matching exception management unit (440) and structure and record it in the form of a log. The matching status change information may include all state transitions occurring during the matching process between donation input data and payment transaction data, such as automatic matching success, automatic matching failure, manual matching approval, manual matching rejection, whether the matching transitions to normal matching after a matching retry, and changes in the matching failure reason code. Based on these logs, the matching policy update unit (450) can quantitatively analyze whether the matching logic is being properly executed and can determine the need to improve the automatic matching criteria if a specific type of matching failure occurs repeatedly.

[0179] Additionally, the matching policy update unit (450) can perform statistical analysis on the frequency of occurrence, error patterns, risk score, processing time, etc., from log data, and dynamically update the matching reliability calculation criteria by reflecting the analysis results in the automatic matching criteria. For example, in campaigns where the omission of unique identification information that can distinguish transactions occurs frequently, time-based or payment terminal identification information-based weights can be increased, and if a pattern with the highest amount error in a specific payment method is identified, the amount-based matching criteria can be lowered to a secondary standard. This automatic update method can flexibly adapt to changes in the donation and payment environments and the introduction of new campaigns.

[0180] Additionally, the matching policy update unit (450) can improve the accuracy of the matching algorithm in the long term by utilizing manual matching results as machine learning-based policy learning data. For example, by identifying condition patterns where manual matching is repeatedly approved by an administrator and actively incorporating those conditions into the automatic matching rule set, the probability of successful automatic matching for the same type of data in the future can be increased. At this time, the matching policy update unit (450) can monitor the administrator intervention rate in real time to track whether the automatic matching performance is improved and automatically adjust the frequency of policy updates as needed.

[0181] Additionally, the matching policy update unit (450) can automatically update exception handling rules. The exception handling rules may consist of conditions such as a re-collection request, a hold flag setting, or a manual verification request performed when an exception occurs, and if a matching failure item remains unprocessed for a long period, the retry cycle can be adjusted or the administrator notification priority can be raised. For example, if a specific type of exception item (e.g., overseas payment data delay) shows a high rate of converting to normal data after several days as a result of analyzing past patterns, the criteria for maintaining the exception processing hold state for that type can be automatically extended.

[0182] Additionally, the matching policy update unit (450) can record and visualize the history of matching policy changes and performance improvement effects, so that the system (1000) operator can clearly identify how the currently applied policy affects the actual matching performance improvement. If necessary, the operator can manually adjust the sensitivity, scope of application, and specific campaign exception handling settings of the policy automatic update function, and the matching policy update unit (450) can manage the automatic update strategy according to these settings.

[0183] Accordingly, the matching policy update unit (450) analyzes matching failure and exception handling logs and intelligently updates automatic matching criteria and exception handling rules, thereby gradually improving the matching accuracy of the system (1000) over time and reducing the need for intervention by an administrator, and consequently, the reliability, level of automation, and overall operational efficiency of donation data processing can be increased.

[0184] The above correction result reflection unit (460) can obtain correction result data entered by a donor or administrator through the donation history portal provision unit (430), and update the matching status or storage information of the donation history information by reflecting the obtained correction result data in the matching reliability calculation criteria and exception handling rules updated in the matching policy update unit (450).

[0185] More specifically, the correction result reflection unit (460) receives the correction request processing result input from the donation history portal provision unit (430) in real time through the donor terminal (20) or administrator terminal (40), and can update the matching status and stored attribute values ​​of the donation history information based on the result data. The correction result data may include a correction request ID, unique identification information or donation amount that can distinguish the corrected transaction, a confirmed payment date and time, a correction reason code, whether the correction was approved, reviewer identification information, etc., and the correction result reflection unit (460) can accurately reflect these information in the donation history database managed by the donation history generation unit (410). For example, if an item that failed to match due to incorrect input of unique identification information is correctly corrected by the donor, the correction result reflection unit (460) can update the unique identification information and switch the matching status to normal matching.

[0186] Additionally, the correction result reflection unit (460) can provide training data to the matching policy update unit (450) so that automatic matching can be successfully performed in situations where the same type of donation exception is repeated, by reflecting the matching relationship information confirmed through manual matching into the rematching logic. That is, the correction result reflection unit (460) does not stop at simple data updating, but accurately transmits the base data necessary for adjusting the matching reliability calculation criteria and supplementing the exception handling rules performed by the matching policy update unit (450), thereby contributing to the continuous improvement of the automatic matching algorithm.

[0187] Additionally, the correction result reflection unit (460) can verify the validity of the correction result data to ensure that the corrected donation history is stably linked to the actual donation activity and payment history. For example, if the unique identification information arbitrarily modified by the donor does not match the actual payment data, the correction result reflection unit (460) can switch the correction request to a pending review state and transmit a signal requesting administrator verification to the matching exception management unit (440). This prevents situations where incorrect correction data is stored or abnormal matching conversion occurs.

[0188] In addition, the correction result reflection unit (460) can automatically update the confirmed donation details information to the donor after the correction, enabling immediate verification in the donation details portal provision unit (430). For example, when a donor is preparing to issue a donation receipt, the correction of unique identification information is reflected without delay, thereby ensuring that the process of generating donation details list and donation receipt data is maintained smoothly. This immediate reflection system can simultaneously achieve improved user satisfaction and administrative processing efficiency.

[0189] Additionally, the correction result reflection unit (460) records both the correction history and the data prior to the change in a version control manner, so that they can be used as supporting data for future audits or as historical data for error analysis. At this time, in order to comply with personal information protection and data security regulations, sensitive information may be stored in a de-identified form and processed so that it is not directly exposed even when a comparison of data before and after the correction is required.

[0190] Accordingly, the correction result reflection unit (460) can improve the overall matching accuracy, data quality, and proof issuance processing efficiency of the system (1000) by immediately and accurately reflecting the correction act performed directly by the donor or manager in the donation history information and matching policy, and can play a role in further developing the automatic matching-based donation data management system in the long term.

[0191] The above receipt issuance unit (500) can automatically generate a donation receipt document based on the donation receipt data generated by the donation history management unit (400), or generate a data file for bulk issuance of electronic donation receipts.

[0192] To this end, the receipt issuance unit (500) may include a format conversion processing unit (510) that converts donation history information or donation receipt data generated by the donation history management unit (400) into a standard format for submission to a tax agency, as illustrated in FIG. 7, and a submission result transmission unit (520) that transmits the data converted by the format conversion processing unit (510) to a tax agency and transmits at least one of the success status information, error verification information, and resubmission request information received from the tax agency to the donation history management unit (400).

[0193] The above format conversion processing unit (510) can convert donation history information or donation receipt data generated by the donation history management unit (400) into a standard format for submission to a tax authority.

[0194] More specifically, the format conversion processing unit (510) can select items subject to submission to a tax agency from among the donation history information integratedly stored and managed by the donation history management unit (400), verify the consistency with the donation receipt data corresponding to the selected items, and then reconstruct the data for submission that conforms to the standard format for submission to the tax agency. At this time, the donation history information or donation receipt data may include at least one of donor identification information, donation amount, donation date, donation type, beneficiary (institution) information, receipt issuance identifier, issuance status, and matching reliability status, and the format conversion processing unit (510) can apply data mapping rules and validation rules to match the field structure, code system, data type, and digit count rules required by the tax agency. For example, if a required identification code or unique institution number is missing when submitting to the tax agency, the format conversion processing unit (510) can classify the record as an error state and link it so that a request for supplementation is performed through the donation history management unit (400) or the donation history portal provision unit (430).

[0195] Additionally, the format conversion processing unit (510) can serialize data for submission into a suitable format by considering the electronic document format adopted by the tax agency (e.g., JSON-based transmission standard, XML-based electronic document standard, CSV report form, etc.). In this serialization process, the format conversion processing unit (510) can apply at least one of split submission or batch submission by reflecting the differences in submission methods by agency, and if submission to multiple agencies is required, records by agency can be automatically separated and converted in parallel.

[0196] Additionally, the format conversion processing unit (510) may perform encryption, masking, or de-identification processing on donor sensitive data to comply with personal information protection standards during the data conversion process. For example, donor contact information or authentication tokens may be replaced based on hash values, and if an identification number essential for submission to a tax authority is included, it may be processed to be included only in an encrypted form by combining it with the encryption policy of the transmission channel.

[0197] Additionally, the format conversion processing unit (510) can automatically assign at least one of the classification code, deduction classification code, and institution type code of the submitted record by applying the classification criteria for donation items that require classification under tax law. For example, since the deduction processing rules may differ depending on the type of beneficiary (institution) even for the same amount, the format conversion processing unit (510) can automatically determine the corresponding code value by referring to the institution metadata stored in the donation history management unit (400).

[0198] Additionally, the format conversion processing unit (510) can perform format checks, range checks, code validation, and data consistency checks on the converted submission data, and can perform automatic removal or merging processing if duplicate records are detected. For example, if duplicate records with the same donation receipt issuance identifier are included, the format conversion processing unit (510) can retain only one submission record and exclude the rest. Accordingly, the format conversion processing unit (510) can convert donation history information or donation receipt data into a standard format suitable for submission to tax authorities, thereby reducing errors in subsequent transmission steps.

[0199] The above submission result transmission unit (520) transmits the data converted by the format conversion processing unit (510) to the tax agency and can transmit at least one of the success status information, error verification information, and resubmission request information received from the tax agency to the donation history management unit (400).

[0200] More specifically, the submission result delivery unit (520) can construct a submission message through the electronic reporting interface of the tax agency system and a secure communication channel, and transmit the submission data generated by the format conversion processing unit (510) in at least one of a case-by-case transmission or an agency-by-agency batch transmission method. At this time, the submission result delivery unit (520) can perform mutual authentication and integrity verification according to the transmission protocol required by the tax agency (e.g., TLS-based encryption channel, digital signature-based transmission protocol, etc.), and can control to prevent data alteration and loss during the transmission process.

[0201] Additionally, the submission result delivery unit (520) can analyze response messages received from the tax agency to identify whether the submission was successful, error verification information, or items requiring resubmission. For example, if a specific field omission, code value error, or period discrepancy is detected, the tax agency may return a response including an error code, and the submission result delivery unit (520) may generate error verification information including an error code, error location, and error record identifier and transmit it to the donation history management unit (400).

[0202] Additionally, the submission result delivery unit (520) may structure and record the submission result values ​​by processing stage (e.g., receipt completed, waiting for inspection, inspection failed, final approval, etc.) or error type, and link to the donation history management unit (400) to update the submission status of the corresponding donation history information. For example, when a resubmission request is received, the submission result delivery unit (520) may transmit resubmission request information, including a list of records subject to resubmission and the reason, to the donation history management unit (400), thereby enabling the donation history management unit (400) to perform a supplementary procedure linked with the correction result reflection unit (460) or the matching exception management unit (440).

[0203] Additionally, the submission result delivery unit (520) may retransmit the same data according to a retry policy if transmission fails due to a delay in the tax agency's response or a network failure, and may perform duplicate verification based on a submission request ID or transaction identifier to prevent duplicate submissions. For example, if the response for the same submission request ID is not received, the submission result delivery unit (520) may control retransmission to be performed only after a waiting time has elapsed.

[0204] Accordingly, the submission result delivery unit (520) can simultaneously achieve traceability of the submission status, rapid response to errors, and automation of resubmission processing by recirculating the submission and response results of the tax agency to the donation history management unit (400).

[0205] Meanwhile, the integrated donation management system (1000) for automatic issuance of donation receipts may be implemented as a computing device comprising one or more processors and a memory in which programs for controlling said processors are stored. Additionally, the memory of the system (1000) may store program modules corresponding to an input interface providing unit (110), a donor identification data generating unit (120), an identity authentication processing unit (130), a payment data linkage receiving unit (210), a payment data verification unit (220), a payment data exception processing unit (230), an automatic matching analysis unit (310), a matching judgment unit (320), a data transmission unit (330), a matching key determination unit (340), a donation history generating unit (410), a multi-tenant management unit (420), a donation history portal providing unit (430), a matching exception management unit (440), a matching policy update unit (450), a correction result reflection unit (460), a receipt issuance unit (500), a format conversion processing unit (510), and a submission result transmission unit (520). As the program modules are executed, receiving donation data, collecting payment transaction data, matching analysis, generating and managing donation history information, issuing donation receipts, and managing submission results may be performed.

[0206] Additionally, the processor of the system (1000) may include a general-purpose CPU, a high-performance server-class CPU, a computing device such as a GPU or NPU for accelerating some operations, may have a single-core or multi-core structure, and may have different instruction set structures such as x86 series or ARM series. The processor may execute an input data receiving unit (100), a payment data collection unit (200), a donation activity analysis unit (300), a donation history management unit (400), and a receipt issuance unit (500) in units of processes or threads operating on the operating system kernel, and may perform control logic for transmitting and receiving data packets with a donor terminal (20), an administrator terminal (40), an external payment system, and an external administrative linkage server (50) via a network. For example, if a multi-core processor is installed in a single physical server, some cores may be prioritized for real-time transaction processing (donation input and payment reception), and other cores may be scheduled to handle the creation of data files for batch issuance of electronic donation receipts, processing of submission results, and matching policy update operations.

[0207] Additionally, the memory of the system (1000) may include both volatile memory and non-volatile memory. Volatile memory can be implemented as DRAM, SRAM, etc., and can enable high-speed access by storing running program code, session data, intermediate results of matching processing, cache data, etc. Non-volatile memory can be implemented as HDD, SSD, NVMe storage, distributed storage system, network storage (NAS, SAN), etc., and can permanently store data that requires long-term retention, such as donation history information, payment transaction history, donation receipt data, receipt document files, data files for batch issuance of electronic donation receipts, matching policy logs, exception handling history, correction result history, submission result history, etc. This memory structure can be used in combination with a database management system, key-value store, file system, object storage, etc.

[0208] Additionally, various program modules that perform the functions of the present invention together with the operating system may be stored in the memory of the system (1000). For example, application programs, microservices, libraries, configuration files, scripts, etc., corresponding to an input interface providing unit (110), a donor identification data generating unit (120), an identity authentication processing unit (130), a payment data linkage receiving unit (210), a payment data verification unit (220), a payment data exception processing unit (230), an automatic matching analysis unit (310), a matching judgment unit (320), a data transmission unit (330), a matching key determination unit (340), a donation history generating unit (410), a multi-tenant management unit (420), a donation history portal providing unit (430), a matching exception management unit (440), a matching policy update unit (450), a correction result reflection unit (460), a receipt issuance unit (500), a format conversion processing unit (510), a submission result transmission unit (520), etc. may be stored. These program modules can be written in various programming languages ​​such as C, C++, Java, Python, JavaScript, and Go, and can operate in the form of web application servers, API servers, background workers, batch processing engines, etc.

[0209] Additionally, the system (1000) may be implemented as a software stack structure including middleware such as a web server, an application server, a database server, a message queue, a cache server, and a load balancer on the OS layer. For example, the web server layer processes HTTP / HTTPS requests from the donor terminal (20) and the administrator terminal (40), and the application server layer can execute business logic such as receiving donation data, receiving payment data, performing matching logic, creating donation history, creating donation receipt data, automatically creating donation receipt documents, creating data files for batch issuance of electronic donation receipts, format conversion, and processing the receipt of submission results. The database server may be composed of a relational database or a NoSQL database and may have a schema structure including a donor table, a donation history table, a payment history table, a receipt table, a submission history table, a matching log table, an exception handling table, etc. The message queue and cache server may support asynchronous task queuing and high-speed data retrieval so that processing can be performed without delay even when a large number of donation requests occur simultaneously.

[0210] Additionally, the system (1000) may run on a single physical server, but to improve scalability and availability, it may be deployed as multiple containers on a container orchestration environment, for example, a cluster based on 'Kubernetes'. In this case, each functional module may be separated into independent microservices and executed as a container unit, and high availability can be ensured through mechanisms such as service discovery, auto-scaling, health checks, and rolling updates. For example, the number of container instances in the automatic matching analysis unit (310) and the matching policy update unit (450) may be automatically increased according to an increase in traffic or batch workload, and the batch worker instances in the receipt issuance unit (500) may be automatically scaled to match periods when batch issuance requests increase, such as the year-end tax settlement season.

[0211] Additionally, the system (1000) may be equipped with a secure network interface for linkage with an external payment system and an external administrative linkage server (50). The network interface card may include a wired LAN, a wireless LAN, a virtual network adapter, etc., and can perform secure data transmission and reception with the external system through TLS-based encrypted communication, VPN tunneling, dedicated line connection, etc. When the receipt issuance unit (500) transmits data converted into a standard format to the external administrative linkage server (50) through the submission result transmission unit (520), transmission may be performed according to the electronic reporting gateway or mutual authentication-based API call specifications required by the external administrative linkage server (50), and the system may be linked so that the received success information, error verification information, and resubmission request information are transmitted to the donation history management unit (400).

[0212] Additionally, the system (1000) may have a redundancy and backup structure for disaster recovery and data protection. Major computing resources, including processors and memory, may be configured in an active-standby structure or an active-active cluster structure, and the database may ensure that donation history information, donation receipt data, data files for batch issuance of electronic donation receipts, and submission result history are not lost even in the event of a failure through real-time replication, snapshot backup, and log-based recovery functions. For example, in the event of a failure in the main data center, the system (1000) instance in the auxiliary data center may automatically take over, allowing donation services and receipt issuance services to be provided continuously.

[0213] Additionally, the system (1000) may include access control, authorization management, audit logs, encryption modules, etc., to satisfy security and personal information protection requirements. Access to the administrator terminal (40) may be restricted according to multi-factor authentication and role-based access control, and sensitive information such as donor identification information, authentication tokens, donation receipt identifiers, and submission identification numbers may be encrypted both during storage and transmission. The audit log records the history of actions regarding who viewed, corrected, and requested the issuance of receipts for which donation details, or checked the results of submission, and can be used as evidence in the event of a subsequent audit or legal dispute.

[0214] Accordingly, the integrated donation management system (1000) for automatic issuance of donation receipts can perform the entire process from collecting donation data to matching, history management, exception handling, correction reflection, automatic generation of donation receipt documents, generation of data files for batch issuance of electronic donation receipts, standard format conversion, transmission to an external administrative linkage server (50), and management of submission results in a stable, scalable, and highly secure manner through a combined structure of software and hardware implemented on a computing device including one or more processors and memory, and can provide a technical foundation that enables various non-profit organizations and donors to efficiently handle donation and receipt issuance tasks in the same platform environment.

[0215] According to the present embodiment, donor donation activity information and payment transaction information can be automatically and accurately linked, thereby ensuring the reliability of donation records and data integrity. Furthermore, by efficiently matching information entered during the donation process with payment history retrospectively, omissions caused by donor input errors or data delays can be minimized, and the burden of manual verification on administrators can be significantly reduced. In addition, donation information from multiple organizations can be managed integrally on a single platform, enabling the operation of large-scale donation data and increasing the accessibility and usability of donation data.

[0216] In addition, donation receipt documents can be automatically generated or data files for bulk issuance of electronic donation receipts can be automatically generated, thereby simplifying the receipt issuance tasks of donors and institution managers, and improving administrative processing efficiency by automating the submission of standard formats to external administrative linkage servers (50) and the feedback of submission results. This integrated processing method can contribute to preventing donation-related errors, improving the overall processing speed and response quality of the service, and promoting a donation culture.

[0217] In this way, the present embodiment provides a stable and reliable donation data and receipt issuance management environment to donors, non-profit organizations, and external administrative linkage servers (50), and can be usefully applied to advance a national donation data utilization system.

[0218] The above description is merely one embodiment for implementing an integrated donation management system that supports automatic tax deductions through post-linking of non-profit organization donation data according to the present invention. The present invention is not limited to the above embodiment, and the technical spirit of the present invention extends to the scope in which various modifications can be made by anyone with ordinary knowledge in the field to which the invention belongs, without departing from the gist of the invention as claimed in the following patent claims. Explanation of the symbols

[0219] 1000: Integrated Donation Management System with Automatic Tax Credit Support 100: Input data receiving unit 110: Input interface provider 120: Donor Identification Data Generation Unit 130: Identity Verification Processing Unit 200: Payment Data Collection Department 210: Payment data integration receiver 220: Payment Data Verification Department 230: Payment Data Exception Handling Unit 300: Donation Analysis Department 310: Automatic Matching Analysis Unit 320: Matching Judgment Unit 330: Data transfer unit 340: Matching Key Determination Unit 400: Donation History Management Department 410: Donation History Generation Section 420: Multitenant Management Department 430: Donation History Portal Provider 440: Matching Exception Management Department 450: Matching Policy Update Section 460: Correction Result Reflection Section 500: Receipt Issuance Department 510: Format conversion processing unit 520: Submission Result Delivery Section 10: Central Server 20: Donor terminal 30: Donation site device 40: Administrator Terminal 50: External Administration Linkage Server

Claims

Claim 1 A system implemented as a computing device having one or more processors and memory for storing programs controlling them, comprising: an input data receiving unit that receives donation input data regarding donor identification and donation intent from a donor; a payment data collecting unit that collects payment transaction data generated through a payment means from an external payment system; a donation behavior analysis unit that generates donation behavior information by performing correlation analysis between the donation input data received from the input data receiving unit and the payment transaction data collected from the payment data collecting unit; and a donation history management unit that generates donation history information based on the donation behavior information generated by the donation behavior analysis unit, stores and manages the generated donation history information in an integrated manner, and generates donation receipt data corresponding to the donation behavior information. The integrated donation management system for automatic issuance of donation receipts is characterized by including a receipt issuance unit that automatically generates a donation receipt document or generates a data file for batch issuance of electronic donation receipts based on donation receipt data generated by the donation history management unit, and the donation activity analysis unit includes: an automatic matching analysis unit that generates matching result data by analyzing a correspondence relationship among at least one of unique identification information, payment date and time, payment amount, and terminal identification information capable of distinguishing transactions between donation input data received from the input data receiving unit and payment transaction data collected from the payment data collection unit; a matching determination unit that provides a matching retry request or manual matching request interface based on the matching result data generated by the automatic matching analysis unit; and a data transmission unit that transmits the matching result data generated by the automatic matching analysis unit to the donation history management unit. Claim 2 The integrated donation management system for automatic issuance of donation receipts according to claim 1, wherein the input data receiving unit comprises: an input interface providing unit that receives donation input data from a donor by providing at least one of a fixed QR code, a dynamic QR code, a shortened URL, a kiosk UI, a mobile / web UI, and a voice-based input UI to the donor; a donor identification data generating unit that generates donor identification data to identify a donor based on at least one of unique identification information capable of distinguishing transactions included in the donation input data, a donor unique identifier, and an institution-specific member identifier; and an identity authentication processing unit that generates identity authentication result data by performing at least one of mobile phone authentication, electronic signature, and biometric authentication, stores the generated identity authentication result data by mapping it to the donor identification data, and provides the identity authentication result data as reference verification data to be referenced when analyzing the correspondence relationship between the donation input data and the payment transaction data. Claim 3 In claim 2, the input interface providing unit receives donation input data from a donor by providing a fixed QR code attached to a guide structure or output medium placed at the donation site, provides a unique identification information input UI upon scanning the fixed QR code, and generates auxiliary verification data referenced when analyzing the correspondence relationship between donation input data and payment transaction data by linking the unique identification information entered through the unique identification information input UI with donor identification data and payment transaction data. Claim 4 The integrated donation management system for automatic issuance of donation receipts according to claim 1, wherein the payment data collection unit comprises: a payment data linkage receiving unit that receives payment transaction data by linking data with at least one of a PG system, a financial institution system, and a simple payment system in a manner that is at least one of an API-based real-time method or a file upload-based post-method; a payment data verification unit that generates verification result data for payment transaction data by selecting at least one of unique identification information capable of distinguishing transactions, payment date and time, and payment amount as a verification criterion for the payment transaction data received through the payment data linkage receiving unit, and performing at least one of time verification, amount verification, and terminal identification information-based verification according to the selected verification criterion; and a payment data exception handling unit that, when inaccurate data is detected in the verification result data of the payment data verification unit, transmits a re-collection request signal for the payment transaction data to the payment data linkage receiving unit or generates administrator verification request information. Claim 5 delete Claim 6 An integrated donation management system for automatic issuance of donation receipts, characterized in that, in claim 1, the donation activity analysis unit further includes a matching key determination unit that sets institution-specific member identifier information included in the donation input data as a key matching key applied to the analysis of the correspondence relationship between the donation input data and the payment transaction data. Claim 7 An integrated donation management system for automatic issuance of donation receipts, characterized in that, in claim 1, the automatic matching analysis unit extracts at least one of payment occurrence location information, payment terminal type information, and payment pattern information included in payment transaction data as a feature quantity, compares and analyzes the extracted feature quantity to determine whether there is a match between donation input data and payment transaction data, and generates donation activity information including the determination result. Claim 8 The integrated donation management system for automatic issuance of donation receipts according to claim 1, wherein the donation history management unit comprises: a donation history generation unit that generates donation history information by classifying donation activity information generated by the donation activity analysis unit by donor, donation institution, and donation item; a multi-tenant management unit that provides multi-tenant-based software services to enable multiple non-profit organizations to manage the donation history information generated by the donation history generation unit in the same platform environment; a donation history portal provision unit that enables viewing or requesting correction of the donation history information managed by the multi-tenant management unit through a donor or administrator terminal; and a matching exception management unit that separately manages information marked as a matching failure item among the donation activity information generated by the donation activity analysis unit and transmits information regarding confirmation or correction request guidance for the item to the donation history portal provision unit. Claim 9 In claim 8, the donation history management unit further comprises a matching policy update unit that logs matching status change information stored in the matching exception management unit and automatically updates matching reliability calculation criteria and exception handling rules based on the recorded log information, characterized in that the integrated donation management system for automatic issuance of donation receipts. Claim 10 The integrated donation management system for automatic issuance of donation receipts according to claim 9, wherein the donation history management unit further includes a correction result reflection unit that acquires correction result data entered by a donor or manager through the donation history portal provision unit and reflects it in the matching reliability calculation criteria and exception handling rules updated in the matching policy update unit to update the matching status or storage information of the donation history information. Claim 11 The integrated donation management system for automatic issuance of donation receipts according to claim 1, wherein the receipt issuance unit comprises: a format conversion processing unit that converts donation history information or donation receipt data generated by the donation history management unit into a standard format for submission to a tax agency; and a submission result transmission unit that transmits the data converted by the format conversion processing unit to a tax agency and transmits at least one of success status information, error verification information, and resubmission request information received from the tax agency to the donation history management unit.

Images