Developing a smart construction supply chain payment management system: an action design research

The global construction sector faces persistent financial instability, exacerbated by recent macroeconomic shocks such as the COVID-19 pandemic, rising interest rates and geopolitical volatility (Selcuk, 2025; RLB, 2025). In Australia, insolvency rates for construction firms remain roughly double those of other industries. Nearly 4,900 cases were recorded in FY24–25, with 50% of firms technically trading as insolvent (Withane, 2025). This pattern is not limited to Australia, as similar trends are evident in the UK and other economies (Mclennan, 2023; Boury, 2025; Van Sante, 2023). Profitability has deteriorated materially across the sector, with smaller firms especially exposed, while COVID-19-related effects continue through worker productivity loss, labour shortages and project delays (Adepu et al., 2025). Although high-profile collapses often involve large corporations, the heaviest losses are borne by smaller subcontractors and, in many cases, home purchasers from the general public (Francis, 2023). This enduring fragility stems partly from the industry's risk-transfer model, which pushes contractual and financial risk down the supply chain. The result is a culture of adversarial relationships, thin balance sheets and short-term survivalism (ACA, 2023).

Recent global economic instability has also intensified the operational pressures that drive late-payment behaviour. Inflationary cost escalation, constrained materials supply, labour shortages and tighter financing conditions have made cash-flow management more volatile across construction supply chains (Singh et al., 2025; RLB, 2025). This is particularly relevant to smaller subcontractors with weaker cash-flow capacity as these pressures make them vulnerable when payment uncertainty is inevitably transferred downstream through contractual hierarchies (Jayan et al., 2026). Payment governance is therefore not only an administrative concern but also a sustainability issue as the reliability and fairness of payment practices shape the economic resilience of the companies delivering construction projects (Van Der Heijden, 2024). Poor payment practices can weaken supply-chain resilience, disrupt project continuity and reduce the long-term organisational sustainability of firms operating within construction delivery networks (Lee et al., 2026; Adaku et al., 2024).

Payment behaviour has long been an indicator of financial stress, contractual disputes, insolvencies and liquidations. Various legislative and administrative controls have been introduced to counter this behaviour, yet these reforms have delivered only partial success (Chong and Diamantopoulos, 2020). These controls regulate behaviour rather than guaranteeing proper execution of contractual payment terms (Hamledari and Fischer, 2021b). As construction progress payments cascade from clients to main contractors and multiple subcontract layers, any delays propagate quickly, eroding trust and liquidity (Ahmadisheykhsarmast and Sonmez, 2020).

In recent years, digital payment management systems have been developed and commercial cloud-based solutions are now available that enable project stakeholders to complete the payment claim application online. This is reported to reduce the administrative effort by 84% (Hamledari and Fischer, 2021a). However, many solutions operate in isolation, lack interoperability and provide limited visibility of cash flow across supply chain tiers (Perera et al., 2020). This siloed nature prevents the creation of a single, trustworthy record of payment behaviour across a project network (McNamara et al., 2025). Consequently, research has yet to demonstrate the feasibility of a project-centric payment system that provides oversight of payment behaviours across a project supply chain.

Despite a growing interest in digital construction payment systems within the construction industry, important gaps remain in the literature. Firstly, many of the existing studies have largely concentrated on automating discrete functions such as progress-payment certification, milestone-triggered disbursement, claim/payment handling and specific payment disputes rather than on project-centric payment governance across a multi-tier construction supply chain (Khalid et al., 2025; Wu et al., 2025). Secondly, while prior studies demonstrate the technical potential of digital and blockchain-enabled payment solutions, much of this work remains application-specific or prototype-specific, leaving limited transferable design knowledge for artefacts aimed at broader payment-behaviour and payment-governance problems (Pittri et al., 2026; Kamel et al., 2023). Thirdly, recent research indicates that the usefulness of digitally enabled construction payment systems depends not only on transaction automation but also on socio-technical conditions such as: practitioner capability, organisational readiness, workflow structure, interdependent approval logic, access and visibility controls, compliance monitoring and reliable cross-party information management (Ameyaw et al., 2024; Singh et al., 2024). However, these conditions remain fragmented across the literature rather than integrated into payment-system designs that enable configuration to the variable contract requirements present throughout a construction supply chain (Tang et al., 2026).

These gaps are increasingly important in an industry characterised by delayed payments, liquidity pressure, supply-chain disruption and insolvency risk. In this context, payment governance affects not only administrative efficiency but also organisational resilience and the economic sustainability of project supply chains (Sreenu, 2026; Chen et al., 2025). Accordingly, this study responds by using Action Design Research (ADR) and affordance theory to develop and refine design principles for a project-centric supply chain payment management system (SCPMS).

The core concept advanced in this paper is that payment problems in construction are not only transaction-execution problems but also payment-governance problems. In this study, an SCPMS is defined as a project-centric digital governance layer for construction payment management. It structures claim data, supports compliant claim creation and assessment, records payment confirmation and enables configurable visibility of payment behaviour across contractual tiers. It is not designed to replace banking platforms, ERP systems or blockchain payment-execution tools. Rather, it coordinates the contractual and governance processes surrounding construction payments.

Affordance theory is used to examine these capabilities because their value depends not only on technical functionality, but also on how practitioners use the SCPMS within contractual and organisational settings. For clarity, this study uses SCPMS to refer to the proposed supply chain payment management system, prototype to refer to the evaluated alpha and beta versions and artefact to refer to the design-science output developed through ADR.

This study addresses the highlighted gaps in current literature by applying an ADR approach to design, develop and evaluate an SCPMS artefact. By linking project participants through a shared digital environment, the SCPMS aims to reduce administrative effort and provide controlled visibility of payment behaviour across the project supply chain. The central research objective is therefore:

To achieve this objective, the study develops an SCPMS instantiation to address a class of construction payment-management and payment-behaviour problems. The artefact is refined through two build–intervention–evaluation cycles following ADR principles (Sein et al., 2011). Accordingly, we consider the first research question:

To assess the expected administrative benefit of using an SCPMS, we also consider a second research question:

Finally, to examine perceived behavioural and governance effects, a third research question is considered:

RQ1 is addressed by deriving initial design principles from the literature and refining them through ADR. Affordance theory is used to clarify relationships among designers, artefacts and users when information technology (IT) artefacts are designed for practice (Pan et al., 2021). The initial design principles are specified through action, materiality and boundary conditions. They are then demonstrated and refined through two ADR cycles. To address RQ2, practitioner estimates of administrative time savings are captured during the second evaluation cycle to provide indicative evidence of expected benefits of the SCPMS relative to current administrative practices. RQ3 is addressed through qualitative practitioner feedback on the perceived behavioural and governance effects of SCPMS use. Finally, the study discusses the success of the ADR process and identifies future research directions.

This study advances both theoretical and practical understanding. Conceptually, it identifies four critical affordances from the literature: structuring, creating, assessing and monitoring. It then develops affordance-based design principles that specify how these capabilities can be embedded in an SCPMS. Practically, it develops and evaluates a feasible prototype through practitioner assessment, showing how these affordances can be operationalised through ADR in support of project-centric payment governance. By capturing practitioner perceptions of SCPMS value, this study explains how such systems may enhance the capability of construction organisations to address persistent payment-management problems, while recognising that live-project performance testing remains a future research requirement.

Despite the fact that payments are essential for project success and the sustainability of a project's supply chain, conducive payment practices are rare (Ramachandra and Rotimi, 2015). Even when head contractors receive timely payments, downstream subcontractors often experience delays, as funds are diverted to other projects. Generally, in a conventional fixed-price contract, parties are financially motivated to minimize cost by “pushing the boundaries” of their contractual obligations in order to increase their profit margin (Hayford, 2018). The resulting payment workflows are administratively onerous, behaviourally inconsistent and highly susceptible to human error (Hamledari and Fischer, 2021b).

Current industry workflows remain heavily intermediated and manual, despite the availability of emerging Industry 4.0 technologies capable of integrating product and cash flows (Hamledari and Fischer, 2021a). Several studies have highlighted the concept of “iContracts” to automate and achieve visibility of progress claims and payments, addressing the lack of alignment between physical progress and financial settlement (Ahmadisheykhsarmast and Sonmez, 2020; Mason, 2024; McNamara et al., 2025). However, these solutions tend to address isolated functions, offering limited system-wide visibility and weak interoperability.

Understanding how to design analytics systems for construction payment management requires a deep understanding of the background domain, specifically the activities that the proposed system should address. To accomplish this, relevant literature in the field of construction management and process was reviewed, identifying four main categories of operational scenarios with the subsequent key activities in construction payment management. This included: (1) baseline commercial claim structure setup; (2) variation and progress-claim compilation and submission; (3) variation and progress-claim assessment and response; and (4) supply chain payment governance. Table 1 summarises the key activities required for the construction payment management process within these four operational scenarios.

The first type of operational scenario involves setting up the claim structure and process for the contract administration by extracting the contractual rules governing variation and payment claim processes along with identifying all influencing variable input data (i.e. payment terms, variation-claim time bars and related variables). Practitioners must also determine the cost items and deliverables to be claimed against from the contract documents. This can be time-consuming and prone to errors due to complex contracts and changing work scope (Motawa and Kaka, 2009). The mapping of a project's contract network allows practitioners to understand the contractual relationship and responsibilities between supply chain participants but is generally limited to only those below any specific organisation. This does not allow easy flow of information and data throughout an entire project network and is exacerbated as projects evolve in size and complexity (McNamara et al., 2025).

The second type of operational scenario involves the actual creation of a variation or payment claim from a contractor, which can often be an arduous and error-prone process which leads to inaccuracies and delay (Mason, 2017). To submit a compliant variation claim, the contractor must carefully compile documented evidence to justify the variation, ensuring that the specific contract rules governing the process are followed meticulously to enable successful approval. For each payment claim, the progress of each claim item (within the payment claim) must be assessed by determining the actual completed work and comparing it to the overall project schedule. Determining the percentage completion of claim items can be highly subjective as poor management and reporting practices often result in inaccurate assessments of progress leading to disagreements between parties (Mason and Potts, 2023). Finally, before any payment claim is deemed complete and compliant, legislative and contractually required documentation must be included with every claim. This can include statutory declarations, certificates of insurance and evidence of the work being claimed, such as progress reports, photos and engineering sign-offs. Due to the manual nature of current practice, incomplete or missing documentation often weakens the claimant's position and hinders the evaluation, which leads to delays in the claims process (Chappell, 2020).

The third type of operational scenario describes the actions that the respondent to a claim must take to finalise the claim before any approval and payment is made. The respondent must first ensure that a submitted claim is compliant in that it adheres to the structure and process specified in the contract along with any legislative requirements including all required documentation. Inconsistent structure and variable document quality from the supply chain can make this a frustrating and onerous task for contract administrators (Jacobs, 2016). Accuracy in assessing the claimed progress, for payment claims, by the respondent is essential for fair and just agreement between the parties. Contractors may use project management tools, site inspections and other methods to accurately measure and report progress but limited visibility of on-site activities may hinder assessment, particularly on large or complex projects (Uff, 2021). This is an area of interest for digital solution providers as various IoT sensors and project management software can now provide real-time data, enhancing visibility and accuracy of assessing on-site progress (Woodhead et al., 2018, Li et al., 2019).

Following the assessment of a payment claim, a respondent may partially or fully disagree with the amount claimed. Should the respondent intend to alter the amount claimed, legislation often deems that an appropriate justification must accompany any proposed payment schedule issued to the claimant. This generally includes a detailed explanation of any rejections or adjustments made to the claim along with any supporting documentation. This can include relevant contractual references for the claim to be agreed and finalised between both parties before any payment is then made (Uff, 2021).

The fourth type of operational scenario identified is the most significant as it addresses the need to oversee and monitor the entire payment claim process, in order to identify problematic payment behaviours and foresee issues that are key indicators of financial distress within a project's supply chain (Dainty et al., 2001; Jacobs, 2016). The ability to ensure compliance of the claim process and oversight of appropriate payment behaviour throughout the supply chain is a level of transparency that has evaded the construction industry due to its reliance on fragmented and uncontrolled solutions (McNamara et al., 2025). Financial instability among contractors leads to disruptions to the supply chain, affecting the timely completion of projects. The ability to facilitate earlier warning of financial distress within a project's supply chain would enable project owners and main contractors to intervene far earlier in order to mitigate the consequential impact of any such event (Stamatiou et al., 2019).

Blockchain- and smart-contract-based approaches form an important adjacent stream within the broader digital transformation of construction payment practices. Prior studies have demonstrated the potential of distributed ledgers, automated triggers and immutable transaction records to improve trust, traceability and payment execution under defined conditions (Hijazi et al., 2026; Luo et al., 2019; Hamledari and Fischer, 2021a; Msawil et al., 2022). These contributions are valuable and have helped establish the feasibility of digitally mediated payment workflows in construction.

This study addresses a different, though closely related, problem space as it does not position the SCPMS as a replacement for blockchain-based payment systems, nor does it claim performance superiority over those approaches. Rather, its contribution lies in addressing the broader class of project-centric payment-governance problems that extend beyond transaction execution alone. In particular, the SCPMS is concerned with the structured setup of contract-commercial data; compliant creation and assessment of claims; role-based organisational workflows; configurable visibility across multi-tier supply chains; capture of payment confirmation from different sources; and monitoring of payment behaviour to highlight financial distress signals throughout the project supply chain. These concerns are only partially addressed in much of the existing blockchain-oriented literature, which more commonly focuses on discrete automation mechanisms, payment release logic or proof-of-concept transaction frameworks (Pittri et al., 2026; Wu and Li, 2025).

The distinction between this study and prior literature lies in both scope and contribution type, as shown in Table 2. The scope of this study focuses on end-to-end payment governance across a project supply chain rather than on a single transaction layer. In terms of contribution type, this study seeks to generate generalisable design principles through ADR rather than to evaluate one narrowly specified technical solution. This also supports the use of affordance theory as it considers how users, artefact features and organisational settings interact in practice, which is critical in a domain where compliance, discretion, trust, visibility and responsibility are distributed across multiple actors. Recent studies support this socio-technical distinction as they show that implementation barriers remain strongly tied to practitioner capability, organisational readiness, digital maturity and institutional support (Ameyaw et al., 2024; Singh et al., 2024).

Importantly, this differentiation does not preclude future technical convergence as a blockchain-based payment engine, banking integration or other third-party payment software could potentially operate as a transaction-execution component within a broader SCPMS architecture. Under such an arrangement, the SCPMS would provide the surrounding governance layer to manage compliant claims processing, while the underlying payment rail would execute and/or confirm transactions back to the SCPMS. This study does not take an anti-blockchain position but rather contributes a broader socio-technical design frame for construction payment management.

To guide the artefact's design, this study adopts affordance theory, a perspective that bridges technical capability and human intention. The original concept of affordance, proposed by Gibson (1977), describes how animals perceive what their environment will enable them to do. In information systems (IS) affordances describe “the potential for goal-oriented actions arising from relations between technical objects and users” (Volkoff and Strong, 2017). This relational lens aligns with the study's objective to design a system that not only optimises administrative tasks but also reshapes behavioural patterns in payment practices.

Affordance theory was selected over a purely adoption-oriented or process-automation lens because the research problem is not limited to whether users accept a technology or whether a task can be digitised. Traditional reforms to construction payment management have focused on standardising procedures and enforcing compliance. While these measures have improved administrative consistency, they have not adequately addressed the complex behavioural and informational dynamics that underpin payment practices (Perera et al., 2020). Construction payment management involves distributed responsibilities, contractual discretion, commercial confidentiality and behavioural incentives that shape how system functions are interpreted and used (Chong and Diamantopoulos, 2020). Persistent challenges of trust, information asymmetry and accountability indicate that payment management is not merely a technical process, but a socio-technical practice shaped by how users perceive and act upon digital system capabilities (McNamara et al., 2025).

Affordance theory, therefore, offers a suitable lens for understanding these interactions as it conceptualises technology through the action possibilities that emerge between system features, organisational users and project-specific boundary conditions (Volkoff and Strong, 2017; Pan et al., 2021). This perspective is particularly valuable in examining how digital artefacts such as the SCPMS may influence and be influenced by, the behavioural norms and governance routines of project participants. It is also consistent with ADR as both perspectives treat artefact design and organisational intervention as mutually shaping rather than separable activities (Seidel et al., 2018).

The concept of affordance has become a popular lens to investigate IS design and following design-oriented IS research (Seidel et al., 2018; Pan et al., 2021), we consider two aspects in order to conceptualise the affordance: (1) the potential interactions between the IT artefacts and goal-oriented actors and (2) the functional properties of the IS that allow for these potential interactions (Seidel et al., 2018). This approach has been adopted by many studies (Fayard and Weeks, 2014; Volkoff and Strong, 2017; Pan et al., 2021) and offers two advantages that make affordance a suitable lens to guide the design of IS artefacts.

Firstly, affordance as a relational concept is useful to address the interactions between the three fundamental entities in design activity: the designer, the artefact and the user. Specifically, designers design artefacts that determine how users use it, while users' requirements inform designers' determination of the artefact (Maier and Fadel, 2009). Secondly, affordance serves IS researchers well by enabling a constructive process that “recognises that the outcome is not preordained” (Volkoff and Strong, 2017). This encourages designers to explore different artefacts or functionality of an artefact, during the design process (Pan et al., 2021).

By applying an affordance-based model, this research interprets ADR activities as continuous negotiation between three entities (designers, artefacts and users), each influencing the others. Designers translate user goals into system functions; users reinterpret those functions within practical constraints; and artefacts evolve as both technological and organisational objects (Maier and Fadel, 2009; Seidel et al., 2018). Affordance thinking, therefore, supports ADR's dual purpose: to solve a practical problem and to generate design knowledge (Pan et al., 2021). It provides a language for connecting specific artefact features to higher-level behavioural outcomes that is required to address the payment-behaviour class of problems.

Drawing from literature and industry practice, we identified four main categories of affordances and functional requirements (affordance constructs) to address each as shown in Table 3: (1) structuring (i.e., mapping contract network and, extraction of the specific contract rules governing the variation and payment claim process); (2) creating (i.e., estimation of claim item progress and/or cost with the attachment of evidence and documentation) (3) assessing (i.e., assessment of claim compliance and assessment of progress and/or cost accuracy); and (4) monitoring (i.e., oversight of process compliance and monitoring of supply chain payment). Together, they represent a framework for embedding trust and accountability within digital construction payment processes.

By grounding artefact design in these affordances, this study ensures that each feature contributes not only to efficiency but also to improved ethical and operational payment behaviour across the supply chain. Affordances are, therefore, not treated as isolated system functions, but as action possibilities that emerge when system features and contractual conditions interact in practice.

This study follows the ADR method as defined in (Sein et al., 2011), in which researchers use real-world situations with the aim of both improving practice and acquiring knowledge (Checkland and Holwell, 1998). ADR combines theory generation with researcher intervention in order to solve current and actual organisational problems (Baskerville and Wood-Harper, 1998), thereby linking theory with practice and thinking with doing (Alexa et al., 2016). The ADR method consists of four stages supported by seven principles (Sein et al., 2011).

The problem formulation stage first identifies and conceptualises a research opportunity based on existing theories and technologies (Hevner et al., 2008) before formulating initial research questions. This stage draws on two principles: practice-inspired research and theory-ingrained artefact (Sein et al., 2011).

• Principle 1: Practice-inspired research

This principle emphasises viewing practical field problems (as opposed to theoretical problems) as knowledge creation opportunities which, for this research, are the problems with current payment claim management practices. A literature review was conducted to determine the state-of-the-art and gain a better understanding of the construction payment management field. This identified the research opportunity to address the construction industry's poor payment behaviours through the development of a conceptual iContract digital solution (Mason, 2024; McNamara and Sepasgozar, 2021) and formulated the Research Questions shown in Section 1. The SCPMS prototype concept is novel for the construction industry and potentially applicable to many construction organisations. Therefore, the research team framed the research as addressing not just a specific problem, but rather, the class of field problems: construction payment behavioural problems, based on this principle.

• Principle 2: Theory-Ingrained Artefact

This principle emphasises that the ensemble artefacts created and evaluated using ADR are informed by theories. These theories should assist with the problem formulation, the identification of possible solutions and the initial artefact creation, which is then evaluated in the building, intervention and evaluation (BIE) stage of ADR (Sein et al., 2011). Following other ADR studies (Pan et al., 2021), this study follows an affordance-based design model to address the interactions among designers, artefacts and users (Maier and Fadel, 2009). Following an affordance-based design model, four categories of affordances (structuring, creating, assessing and monitoring) were identified from the literature review as shown in Table 3.

The second stage of ADR uses the problem framing and theoretical premises identified and adopted in stage one. These premises provide a platform to firstly establish the initial design of the artefact, which is then further shaped by organisational use in subsequent design cycles. This stage draws on three principles: reciprocal shaping, mutually influential roles and authentic and concurrent evaluation (Sein et al., 2011).

• Principle 3: Reciprocal Shaping.

This principle emphasises the inseparable influences of both the IT artefact and the organisational environment. It implies that increased understanding of the organisational context influences the design of the artefact, with the artefact also potentially influencing end-user's practices in the organisational context (Petersson and Lundberg, 2016). This study had input from several experienced industry practitioners who engaged in ongoing dialogue with the research team throughout the development of the SCPMS.

• Principle 4: Mutually Influential Roles.

This principle highlights the importance of mutual learning among the different project participants. Action design researchers bring their knowledge of theory and technological advances, while the practitioners bring practical knowledge of the organisational domain and work practices (Mathiassen, 2002). The complexity of construction commercial management heightened this principle, and researchers relied on the specialist expertise of domain experts. Consequently, the experts equally relied on the research team to guide them on technological advances and theory that could be applied to the project.

• Principle 5: Authentic and Concurrent Evaluation.

A key characteristic of ADR is that evaluation is ongoing and is not a separate stage of the research process. The SCPMS underwent formative testing during the Alpha build and summative testing during the Beta build, aligning with the “IT-dominant BIE schema” of (Sein et al., 2011) shown in Figure 1. In this study, the IT artefact was developed through an iterative process of two BIE cycles:

1. Cycle 1 (Alpha prototype) focused on validating core functionalities derived from initial design principles (claim setup, submission, assessment and monitoring).

2. Cycle 2 (Beta prototype) refined usability, data visibility and workflow integration based on practitioner feedback.

Evaluation combined practitioner interview feedback with participant estimates of administrative time savings. Practitioners assessed whether the prototype's affordances were effectively realised in practice and provided recommendations that shaped subsequent revisions. This concurrent evaluation enhanced credibility and responsiveness, enabling immediate translation of feedback into technical refinements such as role-based access control, retention tracking and multi-user approval workflows.

The evaluation component of this study was designed to align with the authentic and concurrent evaluation principle of ADR. Two build–intervention–evaluation cycles were undertaken with the first cycle functioning as a formative evaluation of the alpha prototype. This cycle focused on whether the initial design principles were being adequately instantiated while also identifying expected and unexpected consequences that required redesign. The discussions followed the theme: “Do the system features allow users to carry out claim and payment processes, achieve compliance and oversee supply chain payment behaviours?”

Participants. The second cycle functioned as a more structured practitioner evaluation of the refined beta prototype. It focused on perceived utility, implementation feasibility and expected administrative benefit within a simulated project context. The participant cohort was weighted towards mid-career project management personnel. This reflected the role these practitioners commonly play in administering variation and payment claims. Participants had an average industry experience of approximately 10.3 years. The use of a guided demonstration format was also influenced by the practical difficulty of obtaining extended time commitments from senior managers while still ensuring consistent exposure to the full prototype functionality.

Demonstration protocol. The beta prototype (Cycle 2) was evaluated in a simulated but practice-based project environment using preconfigured, typical claim-and-payment datasets and staged project scenarios that demonstrated each function of the SCPMS. This approach enabled the consistent demonstration of a complex prototype within a one-hour session while preserving a context that was recognisable to practitioners. Each session followed the same demonstration protocol which covered: project initiation; creation of a project; head-contract work breakdown structure; connected subcontracts; visibility, retention and alert settings; organisational roles and approval workflows; variation and payment claims; payment logging; retention administration; dashboards; and reporting functions. The structured demonstration ensured that all participants assessed the prototype's common set of capabilities before providing feedback.

Data collection and analysis. Two forms of data were collected. Firstly, participants were asked to indicate the level of administrative time savings they would expect from using the SCPMS across seven contract-administration activities demonstrated. The response matrix used a five-point ordinal scale ranging from “no change” to “a few days”. These responses were analysed descriptively and are reported as practitioner expectations rather than observed performance measures. Secondly, open-ended questions were used to elicit qualitative feedback on usability, compliance support, payment visibility, behavioural effects and implementation barriers. Example questions included: “Compared to current practice, do you think using the SCPMS could improve supply chain payment behaviours, collaboration and project success?” Another example was: “What adoption barriers do you think the SCPMS will face to be accepted by industry?” These questions captured unquantifiable qualitative and behavioural benefits that practitioners expected an SCPMS to provide beyond estimated quantitative administrative time savings.

Practitioner comments were used to evaluate the perceived before-and-after effects of SCPMS adoption in relation to the four operational scenarios previously identified from literature (Table 1). Representative quotations from the data were selected to support the scenario-level findings reported in Section 5.3.

Practitioner responses to the open-ended questions were not subjected to formal qualitative or inductive thematic analysis. Instead, they were reviewed deductively against the four operational scenarios, consistent with the ADR objective of evaluating artefact refinement and intervention outcomes. Practitioner comments were used to corroborate the observed differences between current practice and SCPMS-enabled practice, and representative quotations were selected to illustrate these scenario-level findings. Consequently, the interview data from the open-ended questions served an evaluative and explanatory purpose rather than functioning as a standalone qualitative study. This evaluation design provides evidence of practitioner-perceived usefulness, feasibility and design refinement value within a simulated project setting. This should therefore be interpreted as bounded evidence of design validity and anticipated benefit, rather than conclusive proof of field-level superiority over existing systems.

The reflection and learning stage, a continuous stage that parallels the first two stages, moves conceptually from building a particular solution for a certain problem to applying the knowledge gained from the development process to a broader class of problems. This aligns with reflective practice, which emphasises learning from actions and consequences (Schön, 2017). It also reflects organisational learning theory, which distinguishes immediate problem correction from deeper revision of future-shaping assumptions (Argyris and Schoen, 1978). Practitioner feedback informed SCPMS refinements such as visibility settings, role-based workflows, retention tracking and configurable alerts. It also helped revise initial design assumptions concerning transparency, commercial confidentiality, payment confirmation and organisational authority.

This process also aligns with affordance theory as the value of the SCPMS depends not only on technical functionality, but on how users perceive and realise the system's capabilities within contractual and organisational settings (Volkoff and Strong, 2017; Seidel et al., 2018; Pan et al., 2021). In this study, reflection therefore operated as the bridge between situated prototype evaluation and more generalisable design knowledge, consistent with ADR's guided emergence principle (Sein et al., 2011).

• Principle 6: Guided Emergence

The principle of guided emergence captures the interplay between the two seemingly conflicting perspectives of structured external intervention (guided) and organic evolution (emergence). It emphasises that the ensemble artefact reflects the preliminary design created by the ADR researchers (see Principle 2). It also reflects the artefact's ongoing evolution through organisational participant input and authentic, concurrent evaluation (see Principles 3, 4 and 5). Refinement of the artefact can be substantial or trivial, and the research team captured both anticipated and unanticipated consequences to prompt evolution of the design principles throughout the process. During this study, our analysis and evaluation revealed several constructive functionality flaws and technical data architecture issues that were fixed during development.

The objective of the fourth stage of ADR is to formalise the learning from the entire ADR process. Sein et al. (2011) state that the situated learning from an ADR project should be further developed into general solution concepts for a class of field problems (see Principle 1) using the principle of generalised outcomes. By outlining the value of the IT artefact and describing the organisational outcomes, the initial design principles can be revised. With further reflection, these revisions can contribute to refinements of the theories that informed the initial design (see Principle 2).

• Principle 7: Generalised outcomes

The final ADR stage focused on translating project-specific findings into generalisable design principles. Learning was formalised across three dimensions: (1) the problem instance (payment instability as a socio-technical issue), (2) the solution instance (project-centric SCPMS as a class of artefact) and (3) design principles (affordance-driven digital governance) (Alexa et al., 2016). These generalisations contribute to both practice and theory. Practically, they offer a replicable blueprint for developing digital payment systems in construction. Theoretically, they demonstrate how affordance theory can guide ADR to produce artefacts that simultaneously address behavioural and operational objectives (Sein et al., 2011). By concluding with formalised knowledge, this ADR project solves a practical industry challenge and advances academic understanding of how socio-technical artefacts can reshape entrenched behaviours in construction payment ecosystems.

In this section, we detail the first iteration of the two BIE cycles, which occurred between February 2024 and November 2024.

For the first build phase of our ADR project, we focused on RQ1, the identification of the initial design principles, i.e., prescriptive knowledge which describes, “what and how to build an artefact in order to achieve a predefined design goal” (Chandra et al., 2015). We devised our design principles by following a commonly used (Pan et al., 2021) design principle template that contains three characteristics: action potentials (i.e., affordance) through the use of an artefact, the artefacts that make these actions possible and the boundary conditions (Chandra et al., 2015). The template is demonstrated as follows:

For this study, the design principles were formed by applying the concept of affordance with the identified key categories of activities from previous research in the field of construction management and process (Pan et al., 2021). The affordance categories, therefore, explain what the SCPMS enables practitioners to do, while the design principles translate those affordances into prescriptive guidance for developing similar payment-governance systems. The initial design principles that were formulated are seen in Table 4 and are described below.

Firstly, the “Structuring” affordances consist of two constructs: enable connectivity of a supply chain through commercial contract data and enable a consistent commercial structure that will replicate contract commercial data. To realise these affordances, the system requires a data model that connects contracts within the project network. This model must also support a structured commercial framework for replicating contract data within the system.

The data model of the system must consider the following data sets: Organisations, users, project, contract, task, claim item. As the model must “connect” participants of a supply chain through the multiple data sets, careful consideration of the nodal architecture required to enable the appropriate visibility and flow of data was taken in designing the initial data model. The high-level modelling of semantic models (or schemas) is a useful tool for designers to accurately model complex relationship data, prior to implementation (Hull and King, 1987). Semantic models support a higher level of data abstraction. This allows designers to model datasets in ways that more closely reflect how the data is used in practice (Fosdick and Hoff, 2015). Several iterations of the data model design (Feature 1-a) were proposed, as the logic of the model was analysed and challenged by the design team to ensure the model could adapt to any configuration of contract framework. The evolution of the data model, from initial (Cycle 1 design) to final design, is shown in Figure 3.

The ability for users to replicate contractual terms and commercial data within the system, using a standardised structure, is required to enable a consistent approach to subsequent claim, assessment, and monitoring functions that must subsequently be carried out. Within the construction industry, it is common practice to use a Work Breakdown Structure (WBS) to itemise the deliverables of a contract and the associated costs (Cerezo-narváez et al., 2020). The WBS then becomes an updatable central source of truth in which progress, variations and other commercial information are recorded for each contract as the work progresses. To enable a consistent approach for users to create each contract's WBS, the system design (Feature 1-b) allows users to replicate the “Claimable items” from the cost schedule of their contract during the setup sequence. This standard approach ensures that the subsequent claim process aligns and synchronises with structured and controlled baseline data, mitigating the risk of error.

Secondly, the “Creating” affordances require the ability for users to create compliant payment and variation claims and submit them to the “client” of the user's contract. To satisfy this requirement, Feature 2, create and submit variations and payment claims, was designed to allow users to “build” a payment claim by advancing the progress for each claim item within the contract WBS. Additionally, the ability to attach mandatory and additional documentary evidence to each claim was included in order to ensure all legislative and contract requirements are met with each claim submission. Non-compliant and inconsistent claim paperwork is known to cause significant delay in payment and can often be the source of dispute (Brand and Uher, 2010).

Thirdly, the “Assessing” affordances require the ability for users to assess payment and variation claims and respond to the “claimant” while adhering to legislative and contract requirements. To satisfy this requirement, Feature 3, assess and respond to variations and payment claims, was designed to allow users to assess and respond to payment and variation claims. Additionally, the user would also need the ability to attach documentary evidence, to justify any adjustment and have the system monitor the required response timeframe in order for a response to comply with legislation. In New South Wales, Australia, payment claims are governed under the Security of Payments Act (SOPA), and there are timeframes in place for particular steps in the claim-to-payment lifecycle. Failure to comply with SOPA timeframes can limit a party's appeal or recourse rights. Timely responses are therefore essential to maintaining compliance and avoiding commercial exposure or dispute (Brand and Uher, 2010).

Fourthly, the “Monitoring” affordances consist of three constructs: capture payment confirmation, monitor the project supply chain payment and alert of any supply chain payment issues. To address these constructs, the system must capture payment confirmation from the transaction source and monitor users' claim and payment behaviours against contractual and legislative requirements. It must also alert the appropriate parties, within the project supply chain, when reportable non-compliance events occur.

To capture payment confirmation, Feature 4-a was designed to allow payments to be initiated through a third-party payment software (upon claim finalisation), enabling automatic confirmation of successful transactions in real time. To monitor and alert users of relevant non-compliant claim or payment issues, Feature 4-b was designed to allow the system to compare users' actual actions versus the baseline process requirements of the contract and legislation. The feature will then allow the appropriate users (dependent on the contractual framework) in the contract network to receive an alert, in real time, of any non-compliant behaviour.

In the build phase, collaborating with the practitioners in the ADR team, the initial set of design principles was incorporated into a prototype system (Alpha 1.0). The architecture of the system, shown in Figure 2, mainly consists of three parts: database, data model/logic engine and graphic user interface.

To afford connectivity of a supply chain through commercial contract data (DP1-a), we provided a system-architecture data model that would connect each user through a stringent link of each user's “contract node”. This would require contract tasks and subcontract subtasks to be tethered throughout the contract network, requiring hard logical “build-up' of claims from below with a waterfall of payment “trickling down” from above. Three revisions of the data model are shown in Figure 3: Figure 3a presents the initial model, Figure 3b presents the revised model, and Figure 3c presents the final model.

To afford a structured claim submission and assessment process (DP1-b), the system enables users to replicate contract cost-schedule items within a WBS and record key contract particulars, including payment terms. As additional subcontracts were added, the system created an expanding nodal network. Users could then view the WBS for their own contract and any associated subcontracts, as shown in Figure 4.

To afford Create and submit accurate and compliant progress claims (DP2), we provided system features to enable that claims were able to be compiled from the main WBS screen of each contract. Users would increase the progress of each item, to represent work complete, with the system calculating the value of the increase from the previous baseline of claim and payment data. Prior to submitting a claim, the user would also be able to attach further documentation to justify their claim and attach mandatory documents (statutory declaration, proof of insurance, etc.) from an in-system repository within their account. Each claim was then escalated to the contract above until the cumulative claim was finalised by the project client at the top of the contract map. Payment was then released through the supply chain according to the claim amounts agreed at each stage.

To afford Assess submitted claims are accurate and compliant (DP3), we provided system features to ensure that users were guided to assess claims following the necessary legislative and contract requirements and timeframes. To enable this, a claim submission and assessment workflow was developed that would adhere to SOPA requirements, as shown in Figure 5. The system logged the dates of all claim correspondence from each party, enabling it to track the time passed since a claim was received. This offered guidance, to a respondent of a claim, to ensure that responses are made within the necessary timeframes to achieve compliance.

To afford Capture payment confirmation (DP4-a), we provided system features for users to initiate payments from within the system upon finalisation of claims. This was done using the sandpit environment of a third-party payment system that would carry out the transaction upon instruction from the SCPMS. Users could choose to pay immediately upon claim finalisation or choose to schedule the payment for the due date, which was calculated in order to maximise their cash flow while remaining compliant with contractual and legislative timeframes. The third-party software, executing the transaction, would then positively confirm back to the SCPMS that the transaction occurred.

To afford Monitor the project supply chain claim and payment process and Alert of any supply chain payment issues (DP4-b), the system communicates relevant non-compliance events to affected users across the project supply chain. For example, where a claim response was overdue, or payment confirmation was not received by the due date, the SCPMS notified all affected users in the supply chain of the non-compliance. Figure 6 shows a visualisation of a payment default as the alert is communicated throughout the supply chain.

The first evaluation was conducted with construction domain experts and researchers from the ADR team, following six months of system building. The test of the initial system occurred between August 2024 and November 2024 and included one-hour interviews with individual practitioners, with one researcher presenting a demonstration of the prototype SCPMS, before discussions with the interviewee. This process encouraged open discussion guided by the question: “Do the system features allow users to complete the required claim and payment processes, achieve compliance, and oversee supply chain payment behaviours?” The aim of the discussions was to gauge whether the intended designed affordances were realised by the prototype as expected or, if additional considerations were required. In doing so, we found that the evaluation revealed both expected and unexpected consequences as shown in Table 5.

For the instantiation of DP1-a, we found that balancing the diversity of contract frameworks found in industry (lump sum, cost plus, etc.), with the necessary flexibility for task-level connections posed an intricate challenge. The identification of “edge cases' throughout each iteration and the testing of the data model's robustness against complex task configurations proved critical in enhancing the system's adaptability and effectiveness. These technical refinements were carried out during this cycle of development and were deemed resolved as the data model showed the required flexibility for numerous contract frameworks.

For the instantiation of DP1-b, we found that the system feature was useful for replicating a contract's commercial data in a structured manner that was both familiar and efficient for a user. The ease of setting up contracts and subcontracts within the system based on the commercial claim/payment schedule allowed a seamless progression of this task from the usual practice of employing unstructured and uncontrolled spreadsheets. This allowed a consistent and controlled approach within a structured project system.

For the instantiation of DP2 and DP3, we found that the system features effectively enabled both the creation and assessment of variation and payment claims in a compliant and efficient manner. The demonstrations highlighted the benefits of the structured workflow SCPMS users must follow in order to ensure a compliant submission and response. Practitioners found this feature, combined with the alerts function of DP4-b, to be valuable in ensuring tasks are completed within legislative and contractual timeframes.

For the instantiation of DP4-a, we found that the system features were very useful in enabling efficient payment transactions and providing the project team with up-to-date payment status of their subcontractors. The ability to initiate payments automatically upon claim finalisation was deemed by practitioners to provide further risk mitigation against the traditional human-led payment non-conformance issues. Furthermore, giving the project team direct and real-time access to payment status (this information would generally be known to finance department team members) was seen to be beneficial for subcontractor relations.

For the instantiation of DP4-b, we found that the system features were extremely valuable in providing oversight of supply chain payment behaviours. By capturing variation, payment claim and transaction data across the supply chain, the SCPMS enabled critical oversight through its monitoring and alerts functionality. These helped users track internal compliance tasks and receive immediate alerts about non-compliant claim management or downstream payment defaults.

By reflecting on the unexpected consequences identified during evaluation, the ADR team assessed the feasibility of the initial designs and refined the design principles for the second BIE cycle, as shown in the next section. Table 6 makes the traceability between practitioner feedback and beta-prototype refinement explicit and strengthens the audit trail between the first evaluation cycle, the revised design principles and the beta build.

In this section, we detail the second iteration of the two BIE cycles, which occurred between February 2025 and October 2025.

In this design cycle, we refined the initial sets of design principles by reflecting on the unexpected consequences captured during the first BIE cycle.

For the instantiation of DP1-a, it was observed that the initial system design faced significant challenges in addressing the diverse commercial visibility afforded to stakeholders, which often fluctuates from contract to contract, within the project supply chain. Industry experts were concerned that commercially sensitive information, from various levels of the supply chain, could be visible to parties that should not have exposure. The need for visibility settings that would enable multifaceted control to avoid oversharing of commercially sensitive information throughout the supply chain was therefore substantiated.

For the instantiation of DP1-b, the initial feature was too narrow because it only supported progress-based task items. Practitioner feedback showed that milestone and schedule-of-rates task types were also needed to reflect common industry practice. Industry experts also identified the inclusion of retention as a key consideration to fulfil compliance requirements and fully manage contract commercials. Therefore, we redesigned the initial features to reflect the changes in the two structure design principles (changes shown as bold):

For the instantiation of DP2 and DP3, industry experts recommended the inclusion of multi-user workflows as a valuable addition. This function would allow multiple users within an organisation to participate in the claim creation or assessment process. It would also enable organisations to assign permissions according to each user's role, capability and level of seniority. A junior engineer needing a project manager to approve a variation submission over a certain threshold is a prime example of this practice. The ability to define a user's system privileges based on their project role (i.e. financial manager vs project manager vs contract administrator) was also seen to be a necessity for organisational management. Therefore, both DP2 and DP3 were updated as follows:

For the instantiation of DP4-a, industry experts raised concerns over the binary nature of payment transactions which, while technically correct, did not reflect some common practices such as making partial payments. The ability to manually log payments was also identified as necessary where the built-in payment function was not used. This was considered important for adoption by less digitally mature supply chain stakeholders who may rely on basic accounting or payment processes. This led to the following refinement of DP4-a:

For the instantiation of DP4-b, industry experts found that alerts were confined to notification sub-menus, making valuable system data and metrics difficult to access, navigate and share. It was recommended that key metrics should be easily surfaced at both a project and portfolio (of projects) level to ensure that critical information is both easily visible and easy to share with project team members. Industry experts also noted that not all alerts would be relevant to every organisational user, so configurable thresholds were needed to filter alerts to user requirements.

In the second cycle build phase, we operationalised the revised design principles to evolve the initial system features, into an updated beta version of the prototype system, to better address the required affordances. Specifically, for the structuring affordances, we introduced significant visibility controls to ensure that the visibility of downstream parties' commercial information can be configured to align with contractual requirements at the contract setup stage within the system. This allowed multifaceted control during the setup of contracts within the system to avoid oversharing of commercially sensitive information to those upstream of a contract in either the general information screens or in payment default alerts. Figure 7 shows the visibility settings of a contract during the initial setup stage, where a user can dictate the level of visibility of both their subcontracts and all contracts below their subcontracts. This enables the user to dictate the level of information shown to stakeholders when alerts are generated by the SCPMS.

Also to address the structuring affordances, we introduced both “milestone” and “schedule of rates” task types to facilitate additional approaches used in industry to quantify commercial deliverables. Figure 8 shows an example of a user entering various types of tasks during the initial contract setup phase. We also introduced additional functionality to allow users to manage retention progressively during project delivery. Figure 9 shows the retention options for a user, during contract setup, allowing the user to select the nature of retention (cash or bank guarantee) as well as configure the parameters to allow partial and full release. Figure 10 shows an example of the retention overview screen within the system, which gives the user the full details of retention progression as a project progresses.

For both the creating and assessing affordances, we introduced the ability to assign users within an organisation to specific roles on a project. This provided organisational control over the actions and abilities each organisational user can carry out within the system. Figure 11 shows how an organisation's system administrator can select from five roles for users within their organisation as described below:

1. Basic User – Minimum permissions to log in to the system and see basic information.

2. Contract Admin – Can administer Contracts, i.e. carry out all functions within the contract screen but cannot create projects, contracts or subcontracts.

3. Project Manager – Contract Admin privileges plus can create contracts and subcontracts.

4. Financial Manager – Can action all financial functions including schedule payments, pay now and action payment options. They can also add, edit and remove bank accounts for their organisation.

Organisation Admin – All roles' privileges plus the ability to edit the organisation's details, add users, assign user roles and create projects.

We added the ability to create approval workflows for both the creation and assessment of variation and payment claims, which gives organisations the ability to create hierarchical approval workflows for their project team users based on configurable authorisation parameters. Figure 12 shows an example of a project's variation approval workflow based on the project team's individual dollar-value approval thresholds.

For the monitoring affordances, manual logging of full or partial external payments was added so that payment capture was not limited to a single source. Any manual payment logged in the system would be sent to the user's creditor to be confirmed before the payment was deemed to be made by the system to maintain data integrity. Figure 13 shows the payment log screen where a user can log partial or full payment for any finalised claim as well as add a comment and upload a file (such as a bank transfer receipt). We also refined the system alert functionality by introducing configurable user settings. This allows individual users to configure each type of system alert for each of their projects, allowing a user to set an incident $value threshold and even set a time delay so they receive alerts relevant to only them. Figure 14 shows an example of how a user (head contractor) has configured their payment default alerts in order that:

1. They receive an alert immediately if their company causes a default.

2. They receive an alert if a subcontractor has an active default more than 7 days old that is greater than $10,000.

3. They receive an alert if any parties below their subcontractors have an active default more than 30 days old that is greater than $5,000.

We also introduced configurable system dashboards to display the various metrics and alerts generated to improve users' ease of access to system data. Users can create customised dashboards at both portfolio and project levels that present relevant system data through visual aids such as graphs and tiles for use in project team reporting. Figure 15 shows the user options to configure the project dashboards, and Figure 16 shows an example project dashboard with key commercial metrics, payment default incidents, claim non-compliance incidents and various other project information.

The second evaluation cycle was conducted with practitioners and researchers from the ADR team between August 2025 and October 2025, following six months of development to evolve the “alpha” prototype to a revised “beta” prototype. In this evaluation, the refined prototype was demonstrated to industry practitioners, focusing on early-to mid-career project management personnel as these are generally the practitioners who commonly administer variation and payment claims. Due to the difficulty in securing time-poor senior managers for an extended period, a guided demonstration approach enabled a detailed demonstration of the SCPMS within the context of familiar scenarios, which allowed for more feedback.

Feedback was collected during 1-hour interviews with individual practitioners where a researcher presented a consistent guided demonstration of the prototype, structured on various scenarios to exhibit the prototype's functionality including:

1. Project initiation

   • Creating a project, head-contract WBS and connecting sub-contracts

   • Setting up the visibility, retention and alert settings for a contract

   • Setting up organisational roles and authoritative workflows for a contract

2. Claim and Payment management

   • Compiling and submitting variation and payment claims

   • Assessing and responding to variation and payment claims

   • Executing immediate and scheduled payments and logging manual payments

3. Retention management

   • Claiming and approving initial and final retention

4. Oversight and reporting

   • Configuring alert settings for users

   • Creating and configuring dashboard reports for users

The prototype included extensive functionality, and the demonstration simulated a typical construction project in which preconfigured datasets were introduced as the project progressed. A guided approach therefore enabled the full demonstration and feedback collection to be completed within one hour. A total of 14 semi-structured interviews were conducted, with the average industry experience of the participants being 10.3 years and the majority of participants being project managers. The participant profile is summarised in Table 7.

These interviews created an open atmosphere that encouraged discussion, with two types of questions being asked. Firstly, following an SCPMS demonstration, each participant selected what time savings they would expect, by using an SCPMS, across the following seven contract administration activities:

1. Project/contract setup process

2. Submitting variation and payment claims

3. Approving variation and payment claims

4. Finalising payments

5. Overall claim and payment process

6. Retention management

7. Reporting

The response options were: (1) no change; (2) less than an hour; (3) a few hours; (4) one to two days; and (5) a few days. As the response scale was ordinal and the sample size was modest, the results are reported descriptively rather than through inferential statistical testing. Therefore, the data generated are descriptive estimates of expected administrative time saving from the practitioner perspective rather than observed time-and-motion data from a live project. The results are shown in Figure 17 in response to Research Question 2.

Secondly, open-ended questions captured the qualitative and behavioural benefits that practitioners expected an SCPMS to provide beyond estimated quantitative administrative time saving. Rather than conducting formal qualitative or inductive thematic analysis, the interview responses were reviewed deductively against the four operational scenarios previously identified (Table 1). Practitioner comments were used to evaluate the perceived before-and-after effects of SCPMS adoption in relation to those scenarios, with representative quotations selected to support the scenario-level findings reported in Section 5.3.

Following two BIE cycles, the initial design principles were further evaluated and refined. Table 8 (changes are in bold) summarises the final set of design principles from this study. These design principles reflect the ensemble nature of the IS artefact and reflect ongoing refinement by researchers in response to the real-world context drawn from industry practitioners. The design principles, as a nascent design theory, represent the major theoretical contribution of this study and address “Research Question 1” of this study. This prescriptive knowledge not only enhances the understanding of the solution domain but also provides concrete guidelines that can be used to address a class of similar problems for future construction payment management projects.

The two ADR cycles provide a coherent line of evidence from initial problem framing to beta-prototype refinement. Accordingly, the evaluation demonstrates practitioner-perceived utility and design validity within the ADR prototype setting rather than conclusive live-project performance evidence. The results should not be read as comparative performance validation against commercial, blockchain-enabled or enterprise resource planning systems. The quantitative results indicate practitioner-expected administrative benefits. The qualitative findings explain why practitioners perceived the SCPMS as useful for improving process consistency, claim compliance, payment visibility and early identification of payment-related issues. A summary of this study's results, interpretation of results and the boundary of claim, pertaining to each of the research questions, is shown in Table 9.

Findings from this study reveal that affordances are not predefined technological properties but emergent relational constructs that evolve through user interaction and organisational adaptation. Within the SCPMS, the affordances of “Structuring”, “Creating”, “Assessing” and “Monitoring” initially functioned as discrete data operations; however, across successive ADR cycles they matured into behavioural mechanisms that fostered visibility, compliance and trust. Analysis throughout the ADR process demonstrated the progressive realisation of the four affordances. Structuring evolved into linked data models with configurable visibility settings; creating and assessing matured into rule-based approval workflows; and monitoring developed into customisable analytics dashboards with real-time alerts to support transparent communication and early risk detection. These affordances co-evolved with user behaviour, validating the socio-technical reciprocity central to the ADR approach.

A notable theoretical insight was that transparency operates both as a technical property and as a behavioural condition. Although the system enabled visibility, its impact depends on users embracing open communication. This confirms that the affordances adopted are relational, emerging through the interaction of artefacts, users and organisational culture (Volkoff and Strong, 2017).

Practically, the SCPMS demonstrated that well-designed digital tools can simultaneously increase efficiency and strengthen trust in project relationships. Practitioners did not view transparency as beneficial in an unrestricted form. Rather, they perceived value in configurable transparency, where payment-status visibility is balanced against commercial confidentiality through role-based access controls.

The study demonstrates how the four affordances identified jointly transformed payment administration practices. Structuring affordances addressed data fragmentation; creating affordances improved claim compliance; assessing affordances streamlined approval; and monitoring affordances promoted accountability. Collectively, these affordances generated dual impacts: administrative efficiency and behavioural transparency. Practitioners perceived the SCPMS as both a process-improvement tool and a potential behavioural catalyst. By mapping affordances to observed outcomes, this study confirms that digital artefacts can shape human behaviour within organisational settings. The study's findings demonstrate that digital systems grounded in affordance theory can do more than automate transactions; they can restructure behavioural expectations across the construction ecosystem. By embedding rule-based workflows, data visibility and compliance monitoring directly into system design, the SCPMS transforms payment management from a reactive administrative process into a proactive governance instrument.

As illustrated in Figure 18, the conceptual model presents affordance realisation as a dynamic process with four recursive layers. Design features enable core affordances, which activate behavioural outcomes and generate organisational learning that feeds into subsequent design iterations. This cyclical relationship aligns with ADR's principles of reciprocal shaping and guided emergence, showing that affordance realisation is iterative and reflexive rather than linear. Each round of user engagement redefines what the system affords and how it is used.

The model therefore extends existing information systems theory by illustrating how affordances in construction contexts evolve through iterative co-creation between artefact and user. It also confirms that transparency, often perceived as a risk, can become an embedded governance practice when enacted through an appropriately designed digital environment. The SCPMS thus served not merely as a workflow automation tool but as a catalyst for behavioural reform in payment governance. This behavioural shift underscores the relational nature of affordances, which depend not only on system functionality but also on how users engage with technological possibilities (Volkoff and Strong, 2017).

The findings confirm prior studies that describe construction payment administration as a fragmented and manual process that is prone to delay, error and dispute as it is commonly managed through disconnected systems (Ramachandra and Rotimi, 2015; Hamledari and Fischer, 2021a; Perera et al., 2020; McNamara et al., 2025). The practitioner feedback collected in this study supports this view but extends the literature by showing how claim setup, claim creation, assessment, payment confirmation and behavioural monitoring can be connected through a project-centric SCPMS rather than isolated activities. This is important as previous research has highlighted the need for better visibility of payment behaviour throughout a construction project's supply chain tiers but has provided limited design knowledge for achieving this in practice (Dainty et al., 2001; Stamatiou et al., 2019; McNamara et al., 2025).

The findings also extend blockchain and smart-contract payment research. Prior studies demonstrate the potential of digital ledgers, smart contracts and automated payment triggers to improve traceability, trust and payment execution in construction (Ahmadisheykhsarmast and Sonmez, 2020; Luo et al., 2019; Hamledari and Fischer, 2021b; Elghaish et al., 2020; Msawil et al., 2022). However, the SCPMS differs from much of this work by focusing on improving payment governance rather than transaction execution. The results show that practitioners require not only automated payment confirmation but also structured claim workflows, evidence management, role-based approvals, configurable visibility, dashboard reporting and alert mechanisms. This supports the affordance-based view that digital value emerges from the relationship between system features, users and organisational conditions rather than from technical functionality alone (Volkoff and Strong, 2017; Seidel et al., 2018; Pan et al., 2021). The findings therefore contribute a more conditional view of transparency in that supply chain payment visibility can support trust and accountability only when balanced with commercial confidentiality and contractually relevant access controls.

In order to evaluate the overall impact of SCPMS use beyond the administrative time-saving estimates, practitioners were invited to comment on both current practice and how SCPMS adoption could affect the four operational scenarios previously identified in Table 1. By comparing practitioner views of current practice with expected SCPMS-enabled improvements across these scenarios, the perceived behavioural and governance effects of the intervention can be determined (see Table 10), addressing Research Question 3. These expected changes to the operational scenarios are discussed in more detail throughout this section with relevant participant quotations to support the findings. Each quotation is identified by the participant IDs, as shown in Table 7.

The first operational scenario undertaken by managers at the beginning of a project is the setup of the claim management framework and processes that reflect the requirements and obligations of the contract. Currently, managers must have the appropriate level of commercial acumen to extract the commercial framework from the contract and confirm with the other contracted party. This can take time as each party communicates back and forth with uncontrolled documents to achieve agreement.

Each party must also interpret the required contractual and legislative processes to create tracking controls (generally spreadsheets) to guide administrators in following these processes, including any organisational approval workflows. While this is often done successfully, success is determined by the capabilities and experience of individuals rather than standardised and reliable tools.

The practitioners interviewed anticipated that meaningful time could be saved during this scenario, with the SCPMS offering a controlled, collaborative environment to achieve agreement of the appropriate claim framework between parties. Practitioners also acknowledged that the approval workflow functionality, introduced in the beta prototype, could streamline the creation of organisational approvals which could, along with the SCPMS's process tracking capability, support a more consistent approach to contract setup. Forty-three percent of participants estimated that the SCPMS could save 1–2 days when setting up the claim structure and processes, while a further 36% recognised a saving of several hours.

The second operational scenario for managers to carry out during construction is the compilation of variation claims, as required, and the compilation of monthly payment claims. Ensuring all compliance requirements and, when required, supporting evidence accompany each claim submission is generally reliant on both the individual administrator's capability and the standard of organisational systems and processes to guide those individuals. This is deemed to be a significantly onerous task for administrators, which often leads to delayed claim processing, and consequently, payment, from non-compliant submissions due to errors and incomplete submissions. Administrators must understand all compliance requirements and ensure that all valid documentation accompanies each submission, often with little margin for error. This was a particular pain point raised by the interviewed participants that led to regular wasted hours for both contractor and client administrators.

The accurate calculation of payment claims, which are generally submitted cumulatively across the life of a contract, relies on individual administrators to maintain uncontrolled and often inconsistent spreadsheets. While this is often carried out well, human error, particularly when clients adjust claims in their payment schedule responses, can result in compounding calculation errors leading to delayed claim processing and payment. Practitioners acknowledged the efficiency of digitising this operational scenario within the SCPMS's controlled environment, with 64% estimating that multiple hours could be saved for this monthly task. More importantly, the practitioners recognised that while the SCPMS streamlined the submission process, the system's organisational “compliance repository” and submission guardrails would potentially ensure significant mitigation of non-compliant submissions. They also acknowledged the SCPMS would offer more accurate calculation of claims based on the historical, and immutable, data shared between the parties.

However, a consensus among many practitioners was that successful SCPMS implementation would depend on users' technological maturity, particularly less sophisticated subcontractors. While the system proved simple to use, many practitioners highlighted the concern that some users would not have the capability to avail themselves of the system's benefits.

The third operational scenario for managers to carry out during construction is the assessment of variation and payment claims along with executing payment transactions, all within strict timeframes. Currently, the level of effort to assess the accuracy of claim values and compliance is largely dependent on the quality of submission received, which was reported to vary wildly within the industry. Client administrators are responsible for ensuring that all compliance requirements are met and claim calculations are accurate, which is burdensome as human errors at this stage can pose significant commercial and legal risks. The individual's capability and the standard of, often uncontrolled, organisational systems and processes to guide those individuals is the influencing factor that determines the precision of all claims assessed throughout the life of a project.

Client administrators must also ensure that finalised claims are then transitioned seamlessly through any organisational approval processes and handed over to the financial department for timely payment. While sophisticated organisations sometimes have systems and processes that handle these tasks efficiently, this is not common. The majority of organisations experience significant “double entry” of financial data between multiple software systems and organisational departments along with onerous manual tracking of approval progress prior to payment execution.

Practitioners acknowledged that much of the time-consuming effort and risk of error could be significantly mitigated using the SCPMS due to the guardrails in place at the claim submission stage. Fifty-seven percent of practitioners predicted that at least a few hours could be saved every month for this task, while 21% anticipated it could be one or two full days. The practitioners also recognised that the SCPMS's controlled environment would support more consistent and timely claim assessment. Thirty-six percent estimated that an SCPMS could save a few hours for this task, while 43% expected that one or two full days could be saved every month.

The fourth operational scenario concerns project financial reporting and oversight of supply chain payment risk during the construction phase. Managers are required to report regularly on project financial status, including active or emerging payment issues. In Australia, contractors may also be required to provide statutory declarations confirming that subcontractors and suppliers have been paid. However, this mechanism relies on self-disclosure and provides limited independent verification of downstream payment behaviour.

Existing mitigation strategies also have limitations. Financial due diligence reports are costly and usually provide only a snapshot in time, while direct contact with subcontractors can be perceived as undermining the upstream contractor. Subcontractors may also be reluctant to disclose payment concerns for fear of damaging future work opportunities. As a result, financial distress is often hidden until late in the project, offering little early warning and limiting the ability of clients and project managers to intervene before payment problems affect delivery.

Contract administrators must also regularly provide progress reports which include the financial status of a project and any active or potential issues. These reports are commonly done on a monthly basis to accompany payment claim submissions to a client. Compiling the required data is onerous for administrators, who often rely on uncontrolled spreadsheets. This data may be weeks or even months out of date, particularly when it is collected from deeper tiers of the supply chain. Practitioners recognised that the SCPMS could streamline reporting through configurable and automated dashboards, with 86% estimating time savings from a few hours to one or two days. Practitioners also emphasised that real-time SCPMS data from deeper supply chain tiers could improve the currency, reliability and accuracy of reporting.

A particularly important value that practitioners recognised was the behavioural impact that an SCPMS could have through improved oversight of payment behaviour within a project's supply chain and real-time alerts for non-compliance. Supply chain financial distress and potential insolvencies are regular items on project risk registers, with current mitigation approaches often proving ineffective and costly. Practitioners acknowledged that, while a specific administrative time or project cost saving for this function would be speculative, the potential avoidance of such high-impact issues could be significant. Depending on the size of the project and the affected parties, historical instances from the industry have shown the magnitude of such events. While a system cannot remove insolvency risk, greater visibility of payment status and non-compliant behaviour could support earlier intervention and potentially reduce avoidable financial issues that impact project delivery.

This study set out to develop and refine design principles for a project-centric SCPMS capable of improving transparency, administrative consistency and payment-governance capability within construction project supply chains. Using an ADR approach informed by affordance theory, the research moved from problem formulation and initial design to iterative artefact refinement through two BIE cycles. In doing so, it produced design knowledge organised around four interrelated affordance categories: structuring, creating, assessing and monitoring. Taken together, these affordances frame construction payment management not simply as a transactional problem, but as a socio-technical governance problem involving multiple actors, contractual relationships, evidentiary requirements and behavioural risks. More specifically, the paper clarifies how a project-centric SCPMS can connect contract-commercial data, support compliant claims, capture payment confirmation and surface payment issues through configurable visibility and alerts. This framing is important as it defines the distinct payment-governance layer provided by an SCPMS, in contrast to transaction-focused blockchain, smart-contract or enterprise payment systems.

The study contributes to theory by extending affordance-informed ADR into the underdeveloped domain of construction payment-governance systems in two principal ways:

1. It extends affordance theory to explain the emergent behavioural dynamics of digital artefacts in construction and

2. It enhances ADR as a framework for socio-technical system design in project-based environments.

Existing information systems literature often conceptualises affordances as predefined technical properties embedded in artefacts (Gibson, 1977; Maier and Fadel, 2009). In contrast, the findings from this study demonstrate that affordances are emergent, relational constructs that evolve through iterative interaction between users, artefacts and organisational context. It shows how affordances can be used to connect system materiality with user action and implementation context, thereby moving beyond broad claims of digitalisation benefit. The refined design principles demonstrate that supply chain payment-management artefacts must support not only automation but also visibility, role-based discretion, evidentiary compliance, contractual confidentiality and behavioural monitoring.

This evolution underscores that affordances are not static design features, but co-created outcomes shaped through continuous negotiation between technological capability and social practice. As illustrated in Figure 18, the process of affordance realisation within the SCPMS followed a dynamic trajectory: system design features enabled core affordances; these affordances, in turn, generated new user behaviours and organisational learning, which subsequently informed further design refinement. The model highlights that if an SCPMS artefact is to actively support the reconfiguration of relational norms and governance practices, then merely automating administrative tasks will not suffice.

The research also advances ADR by embedding behavioural and institutional perspectives within its traditional design–build-evaluation–reflection cycle. Most ADR studies focus on technical artefact refinement, yet few address how design interventions reshape social processes such as trust, transparency and accountability. By integrating affordance thinking into ADR, this study demonstrates a dual design logic (technical efficiency and behavioural transformation) that bridges functional performance with organisational learning. Beyond its technical role, the SCPMS became a shared frame of reference, illustrating how digital artefacts can serve as boundary objects that coordinate understanding and collaboration across project stakeholders. This integration refines ADR's theoretical utility for complex socio-technical domains such as construction, where institutional resistance and contractual fragmentation often inhibit technology adoption.

Together, these contributions reposition digital design research in construction from a focus on tools and efficiency to one centred on relationships and behaviour. The SCPMS case demonstrates that affordance-driven ADR can yield artefacts that are simultaneously functional and adaptive and offer a pathway toward more sustainable models of digital governance in construction and other project-based industries.

This study has significant practical implications for designing digital systems that address construction payment management. The SCPMS demonstrates how socio-technical innovation can simultaneously improve process efficiency and reshape payment behaviour within complex supply chains.

The practical implications vary by stakeholder group. For project owners, the SCPMS offers a possible governance mechanism through which downstream payment behaviour can become more visible, thereby improving oversight of financial stress signals and reducing the likelihood that critical issues remain hidden until they become project-threatening. For main contractors, the SCPMS provides a structured environment for claim administration, workflow control and earlier identification of non-compliant or distressed payment behaviour within lower tiers of the supply chain. For subcontractors, the principal value lies in more consistent claim pathways, clearer evidentiary requirements, greater visibility of claim status and the potential for a fairer and more predictable payment environment.

Beyond efficiency, the SCPMS addresses the industry's most persistent structural problem: the lack of transparency in supply chain payments. Its project-centric data architecture provides real-time visibility of claim and payment status across all contractual tiers, offering early warning of potential delays or non-compliance and automatically notifying relevant parties to enable timely intervention. For project owners and financiers, this capability may reduce exposure to insolvency risk and can enhance financial governance by making payment performance auditable in real time. For subcontractors and suppliers, it could ensure payment integrity and predictability, which are essential factors for stability, innovation and long-term growth.

The implications also differ across procurement and commercial settings. In lump-sum environments, the structuring and assessing affordances may be especially important in creating a consistent basis for claim assessment and visibility of downstream obligations. In cost-plus or open-book settings, configurable visibility and role-based permissions become particularly important because greater transparency must still be balanced against commercial confidentiality. Across these contexts, the beta refinements indicate that SCPMS adoption depends on reflecting real contractual variation rather than imposing a generic workflow. From a sustainability perspective, improved payment visibility and governance may also strengthen supply-chain resilience by reducing the cascading financial instability that commonly affects subcontractor networks during periods of economic volatility.

Although the prototype SCPMS developed in this study was configured primarily for the Australian market, its underlying affordances, design principles and system logic are broadly applicable across jurisdictions. As payment administration and cash-flow instability are persistent global challenges, the SCPMS system architecture is intentionally designed with a configurable logic engine. This adaptability enables stakeholders in any jurisdiction to tailor workflows to local legislative and contractual requirements. This supports the creation of scalable, project-centric payment systems that accommodate diverse procurement frameworks and compliance regimes while improving payment behaviour and financial resilience throughout the supply chain.

The SCPMS should be understood as a governance layer that may connect to, rather than necessarily replace, existing payment execution systems. The beta prototype demonstrated several payment-confirmation pathways: immediate or scheduled payment through a third-party payment environment, manual logging of externally processed payments, partial payment recording and creditor confirmation of logged transactions. This distinction between payment governance and payment execution is important for implementation, as many construction organisations already rely on legacy banking platforms, enterprise resource planning systems, accounting systems and project controls tools.

Future SCPMS deployment should therefore prioritise interoperability through secure data exchange with enterprise resource planning systems, accounting systems, banking/payment rails and potentially building information modelling (BIM) or project-progress software tools. Under such an arrangement, external systems may execute transactions or supply evidence of progress, while the SCPMS manages the surrounding contractual structure, approval workflow, compliance documentation, visibility controls, alerts and reporting. This modular interpretation would also enable the possibility for blockchain or smart-contract infrastructure to operate as a transaction-execution component within a broader SCPMS technology stack.

For policymakers and industry bodies, the study suggests that digital payment reform should not focus solely on statutory compliance or isolated transaction technologies. It should also consider information structure, behavioural visibility and auditable governance mechanisms that can improve the practical execution of payment obligations. This is especially relevant where existing protections rely on self-declarations or after-the-fact dispute processes that do not provide real-time insight into whether payment obligations are being fulfilled throughout a project's supply chain.

For teaching and professional development, the study provides a practical case through which students and practitioners can understand the interaction between construction law, contract administration, project controls and digital governance. The SCPMS case illustrates why digital transformation in construction is not simply a matter of automating an existing task; it requires careful design of responsibilities, data visibility, workflow authority and user incentives.

The broader societal implication is that payment transparency is connected to the economic sustainability of the built environment. Delayed and opaque payments destabilise project delivery, transferring financial stress to smaller firms, workers and households. A project-centric payment-governance system may therefore contribute to more sustainable construction supply chains by improving accountability and reducing the information asymmetry that allows harmful payment behaviour to persist.

Several limitations must be acknowledged. The evaluation was conducted in a simulated project setting rather than a live project environment; the participant group was modest in size; and the quantitative component captured expected administrative benefit rather than directly measured time savings. The findings should therefore be interpreted as bounded, practitioner-evaluated evidence generated through prototype demonstration, not as live-project proof of comparative field performance. Furthermore, the study does not benchmark the SCPMS against existing commercial payment systems, blockchain-enabled payment systems or enterprise resource planning tools. The reported administrative time savings therefore represent practitioner-perceived anticipated benefits from a guided prototype evaluation, rather than comparative performance evidence from live project deployment.

In addition, as the study followed an ADR approach, the researchers were actively involved in artefact design, demonstration, evaluation framing and interpretation. This creates potential for researcher bias, including confirmation bias and influence over how participants interpreted the prototype. This limitation was partly managed by using structured demonstration scenarios, consistent evaluation prompts and predefined operational scenarios. However, future independent evaluations would strengthen the robustness of the findings. Finally, although the prototype was configured with Australian security-of-payment requirements in mind, payment legislation, procurement norms and data-governance expectations vary across jurisdictions.

Future research should proceed in four directions. Firstly, longitudinal field trials are needed to assess how SCPMS use affects actual claim-cycle times, payment behaviour, dispute incidence and administrative burden across live projects. Secondly, comparative field trials across live projects would benchmark SCPMS performance against existing payment-administration systems, blockchain-enabled payment solutions and conventional spreadsheet-based workflows. Thirdly, comparative studies should examine SCPMS implementation across different procurement models, project scales and regulatory jurisdictions. Lastly, technical research should examine integration with enterprise systems, banking/payment systems, BIM-enabled progress verification, IoT data and potentially blockchain-enabled transaction layers. These studies would allow the design principles developed here to be tested, extended and converted into more mature design theory.

In Australia, optimising the construction industry has become increasingly critical to combat the housing crisis and government and industry have identified supply-chain payment stability as a priority issue. In this study, we adopted an ADR approach to investigate how a project-control system should be designed for the supply-chain payment-management domain that would directly address this problem.

This study developed and refined design principles for a project-centric SCPMS intended to improve construction payment administration and governance. In response to RQ1, the study identifies structuring, creating, assessing and monitoring affordances as the basis for SCPMS design. In response to RQ2, practitioner feedback indicates that such a system is expected to reduce administrative effort across key claim-and-payment activities, although these findings remain perceived rather than live-measured. In response to RQ3, practitioners perceived the SCPMS as capable of improving payment behaviour by increasing process consistency, claim transparency, payment-status visibility and earlier identification of payment-related issues.

The central contribution is not that the prototype proves superiority over all existing payment technologies, but that it provides a design-oriented blueprint for addressing construction payment management as a socio-technical governance problem. By linking ADR, affordance theory and practitioner evaluation, the study offers a foundation for future field trials and for the development of interoperable payment-governance systems that can support more transparent, accountable and economically sustainable construction supply chains. The findings position payment governance as a key contributor to sustainable project delivery. By improving financial transparency, accountability and early visibility of payment distress, an SCPMS may support more resilient procurement ecosystems and the long-term organisational sustainability of construction supply chains.

The construction industry contains many repetitive, rule-based administrative tasks that AI-enabled technologies could optimise where reliable and structured datasets are available. An SCPMS could provide a traceable and consistent data source for claim and payment information across a project's supply chain, supporting improved financial risk management through greater payment visibility. Over time, this structured data environment could provide a foundation for future research into more advanced automation of construction contract administration and dispute-resolution processes.

Ethics statement: This research was approved by the Human Research Ethics Committee (HREC) of the University of New South Wales, Sydney, Australia. HREC applies the principles outlined in the National Statement on Ethical Conduct in Human Research to ensure that projects promote and facilitate ethically sound research that is of benefit to the community, that researchers and research students respect the rights and welfare of human participants in research and that any risk of unfair burden or harm from research procedures is minimised. Reference: HC190366.

Declaration of Generative AI and AI-assisted technologies in the writing process: During the generation of this paper, the authors did not use generative AI and AI-assisted technologies.