By Artem Korsakov ·
Material requests in construction are useful when they show what to buy and which work it will support. For an industrial contractor, a request saying “we need cable” leaves too many questions: which grade, for which section, under which specification, in what quantity and for which operation. Automation starts with this data and ends with confirmation of the actual delivery.
In short: link each item to a section and a requirement. Separate the quantity requested, approved, ordered and received. Keep the date the site needs and the supplier's promise separately.
A request is not an order to a supplier
The site foreman describes the requirement. The buyer checks how to fulfil it: stock, transfer from another site, purchase or client supply. An order to a supplier may combine several requests. Conversely, one request may be fulfilled by several deliveries.
This separation also exists in off-the-shelf products. The description of the supply module in 1C:ERP for Construction Companies (USO) (1C is a widely used Russian business accounting platform) separates requirements, purchasing, delivery, receipt and client-supplied materials. A small service only needs to support the relevant part of this chain while keeping the distinctions between events.
Supplying construction sites gets complicated when material is already recorded as purchased but is sitting in another warehouse, has not been delivered to the site or requires a document check. That is why the status “purchased” must not automatically mean “work is supplied”.
Which fields a site foreman needs
The form is best built around one item, with the option to add several related lines. For identification, the accepted reference list is used, and free description is left for explanations. You cannot count on the buyer always guessing the product from a photo.
The minimum set of fields:
- Site, section or system, and link to the work package.
- Name, designation and the required unit of measure.
- Quantity, the date needed on site and the basis for the requirement.
- A link to the specification or drawing, with the version stated.
- Requirements for completeness and accompanying documents, if defined.
- The initiator, the person responsible for receiving and the delivery location.
For equipment, agreed parameters, components and unloading conditions are added. The list of technical requirements is defined by a specialist. The form allows a specification to be attached; the site foreman does not need to retype the technical document.
Who approves what
The internal review should answer specific questions. The technical department confirms the technical reference, the project manager checks need and priority, and procurement clarifies how it will be supplied. Financial approval depends on the accepted purchasing procedure. It is not sensible to send every request to all managers.
The route can change depending on conditions: a new product, exceeding an internal limit, a material substitution, an urgent need. The system keeps the decision, the author and a comment. A return needs a clear question, for example “clarify the unit of measure”. A single “reject” button is not enough for this.
Automating construction procurement will not fix blurred authority. Before development, define who is entitled to approve a technical equivalent, who approves costs and who is informed of a change in timing. These may be different participants.
How to account for a partial delivery
A hypothetical example: the section requested 1,000 metres of material, all 1,000 were approved, and the supplier confirmed 600 for the first date and 400 later. The documents for the first delivery state 600 metres; 580 were physically received and accepted. The shortfall in the first batch is 20 metres; another 400 are expected in the second batch. In total, 420 metres have not yet been received. The system stores these quantities separately and shows who is clarifying the shortfall. The original request is not replaced with the actual figure.
At item level, it is useful to show: needed, approved, covered by a source, expected, received and still to be supplied. Receipt includes the date, the recipient and any recorded discrepancies. Processing accounting documents stays in the established accounting process.
Several shipments can be linked to one order. If such detail is not yet available, the first version should at least allow delivery events to be added to a request line. A single overall completion percentage is not enough for decision-making.
The states of one requirement are different and cannot be added together. A request is not closed when the delivery note is received. AI helps match the delivery note lines with the request and highlight the discrepancy; the quantity is confirmed by the receiving employee. The manager sees what remaining requirement is still not supplied and who is handling each open question. Training example in metres: requirement 1,000, 600 in the documents for the first batch, 580 received. 420 not received: a shortfall of 20 and a second batch of 400.
Substitutions, client-supplied materials and long lead times
If an equivalent is proposed, the original requirement is kept. The proposed substitution, the justification and the decision of the authorised technical participant are recorded separately. The buyer's agreement on price does not replace technical approval.
For client-supplied materials, it is important to see, besides the supplier, the party that has undertaken to provide the item. An internal register can remind you of the deadline and store correspondence, but it does not change the contractual allocation of obligations.
Equipment with long manufacturing times needs to be considered earlier than a regular request before a shift. Add the date by which the order must be placed, planned milestones and confirmed updates from the supplier. If the forecast is unknown, show “not confirmed”. An invented date is worse than such a label.
When the work schedule changes, the requirement is reviewed. Otherwise, procurement will keep buying a cancelled item or bring a quantity that has nowhere to be stored. Closing a request requires a reason: supplied, cancelled, substituted or merged with another.
What the first version of the service looks like
A realistic start: a mobile form, reference lists of sites and materials, a review route, a buyer's workspace and a delivery register. Each item has a history, attachments, a person responsible and dates. The manager sees overdue decisions and unconfirmed deliveries.
Tracking material requests can start without automatic write-off from the warehouse. But users must be clearly shown whether stock levels are current and as of what date they were obtained. If data is entered manually, it must not be presented as live stock from the accounting system.
The neural network parses the request; a person chooses the material
The input is an email, a spreadsheet or the site foreman's text. The model turns it into draft lines: original name, designation, quantity, unit, section and required date. The source fragment is kept alongside. If all it says is “cable like last time”, the assistant raises a question. It does not fill in the grade itself.
The buyer checks the lines against the reference list and the attached specification; the technical participant checks whether the chosen item is acceptable. After confirmation, the record enters the supply queue. AI can prepare a question to the author about missing data or a draft email to a supplier. The order is not sent automatically.
Training example: AI parses a site foreman's request for cable. An incomplete description turns into a question for the author. AI does not fill in the cable grade based on a previous request.
If the company already uses the 1C:ERP USO procurement module, it is worth first checking its configuration and ability to accept structured data. An additional product is needed for the inconvenient input from the site or for parsing emails. The chain: email/form → AI draft → verified requirement → existing procurement records. In the first version, an export of approved lines is possible; two-way exchange depends on the configuration and permissions.
Pilot quality is assessed separately for grades, units, quantities and missing fields. Time savings do not justify silently wrong products. Materials from a confidential project are passed to the model only in a permitted environment.
How to check the result
Before the pilot, select comparable requests for one site or type of work. Measure the time from submission to acceptance by procurement, the number of returns for clarification and the share of items with a confirmed date. For deliveries, separately count on-time arrival by the required date and compliance with the approved quantity.
Separate the causes of failure: a late request, slow approval, a payment delay, manufacturing, delivery, site access. Software can make a delay visible but will not remove all its causes by itself.
Do not assess the effect only by the number of forms filled in. It matters more whether items have stopped getting lost, whether re-entry has decreased and whether the manager can understand what is still preventing the work from being supplied. Cost savings are confirmed separately, on agreed actual costs.
How to see the risk of work stoppage in advance
A late delivery matters because of its impact on specific work. Link the request item to a section and the date of need. If the supplier reports a postponement, AI can identify the new date from the email and suggest updating the card. The buyer confirms the information; the manager sees which work and which remaining requirement are affected.
This makes it possible to check the consequences before downtime occurs. The system can show a request for a decision: clarify a partial delivery, agree on another date or pass a question about substitution to a specialist. It must not choose a technical equivalent by a similar name on its own. When the price changes, a new version of the offer and a separate purchasing decision are stored.
Receiving on site: quantity does not yet mean ready for installation
After material arrives, it is useful to separate physical presence, quantity receipt and clearance for use under the accepted process. For example, a batch arrived in full, but the set of accompanying documents needs clarification. In the summary it is shown as on site, while whether the corresponding work is supplied remains a separate question.
For the hypothetical 580 metres received in the example above, the storage location and the reservation for the section are stated. If 80 metres were then moved to another job, the original requirement must not remain supplied for the same 580. The transfer event is linked to an authorised change in allocation. The requirement register receives an update from warehouse records or a confirmed reconciliation. It does not calculate the balance from correspondence.
For returns and defects, the reason, quantity, source of the decision and expected replacement are kept. You cannot simultaneously reduce the delivery and add the whole original request back to purchasing. The buyer must see the net remaining requirement after confirmed receipts, returns and reallocations.
How to detect a duplicate request
The same material may legitimately be needed by two sections, so a matching name does not mean a duplicate. The check compares the site, work package, specification, quantity and open requirement. AI suggests candidates for review and shows why it linked the records. The buyer confirms the merge or keeps the requests separate.
For equipment with long manufacturing times, it is useful to separately record the validity period of the offer and the moment manufacturing time starts: an advance, documentation approval or another confirmed condition. The same “12 weeks” in two emails may mean different dates. At the first stage, the assistant extracts the condition, and an employee confirms the calendar date after checking the basis.
Using your anonymised requests and an example of a partial delivery, we can build a prototype procurement workspace: with the remaining requirement, people responsible and verifiable parsing of incoming messages.
Sources
1C:ERP USO, purchasing and material supply. Checked 18 October 2026. The recommended process requires adaptation to the company's contracts, roles and accounting.
Related reading: Comparing supplier quotes with AI in construction procurement; Supplier invoice reconciliation: order, receipt and help from AI.
Частые вопросы ### Can requests stay in a messenger?
Yes, if the message creates a verifiable record in the register and the author receives its number and status. An unconfirmed parse of a message must not automatically become an order.
Is full warehouse accounting needed right away?
Not always. You can start with requests and delivery events. But movements and stock should be taken from an agreed source, without creating a second, uncontrolled set of books.